Conceptos Generales de SolrCloud

Las colecciones se componen de un o más shards. Los shards tiene una o más replicas. Cada replica es un core.

Un nodo es una máquina virtual de Java que ejecuta Solr, normalmente se le llama servidor. Cada core de Solr se puede considerar un nodo.

Cuando levantas un nuevo core en modo SolrCluod, se auto registra en Zookeper. Esto implica crear un nodo Efímero (Ephemeral), que se marcha si la instancia de Solr se cae, así como la información registrada sobre el core y como contactar con él. Los clientes inteligentes y los nodos del cluster pueden utilizar la información para determinar con quien necesitan hablar para completar la solicitud.

 

1.1          Clusters

Un cluster es un grupo de nodos de Sorl controlados por ZooKeeper como único elemento, siempre se puede hacer una solicitud al cluster y si es capaz de responderla, puedes estar seguro que se manejará de forma única y durable y no supondrá perdida de datos

1.2          Crear un Cluster

El cluster se crea tan pronto como registramos en Zookeper más de una instancia Solr

1.3          Leader

El concepto de leader es similar al de master en una réplica de Solr tradicional El leader es el responsable de asegurarse que los replicas están al día con la misma información almacenada en el líder. Sin embargo, en SolrCloud puede existir más de un master y uno o varios slaves, dependiendo del número de shards.

1.4          Importación de datos

El programa cliente, manda el documento a cualquier shard del cluster, para que lo indexe. Si el nodo que recibe la petición es una réplica, hace la query y manda el documento al leader para que lo procese. El leader añade el documento al log de transacciones, lo indexa y lo manda a todas las réplicas para que lo indexen. Si la actualización se realiza en el leader, pero falla en las réplicas, al cliente se le responde con status exitoso. Cuando las réplicas se recuperen, se sincronizarán con el leader. Si la réplica se ha quedado muy lejos de la sincronía, el sistema hace un recovery completo de la réplica. Si la actualización falla, porque el esquema se está recargando y algunos han acabado, pero otros no, el leader les dice a los nodos que la actualización ha fallado y comienza el procedimiento de recuperación

1.5          Balanceador de carga

SolrCloud automáticamente balancea la carga de las llamadas, y no necesita tener un balanceador de carga enfrente, como el caso de la arquitectura tradicional. Pero todavía es recomendable tener un balanceador enfrente o un cliente inteligente que haga la petición al cluster. Imagina que se hacen todas las peticiones al mismo nodo, que se encargara de pasarle la petición al leader y el leader determinara que shard tiene que procesar esa información y luego se la mandara al leader de ese shard.  Si la aplicación cliente sabe a qué shard debe hacer la petición la vuelta inicial se evita el cliente inteligente tiene un balanceador que distribuye la solitud basándose en principios round-robin

Si se mandan todas las peticiones al mismo shard y ese shard se cae, todas las peticiones se carean. Para contemplar es simple punto de fallo, SolrJ permite que se referencia al ZooKeeper en vez de al nodo Solr. Porque ZooKeeper siempre conoce el estado del cluster, nunca hará una petición a nudo que no esté disponible.

1.6          Recovery

Se crea un log de transacciones en cada nodo, en él se anota cada cambio. El log se utiliza para determinar que contenido del nodo se debe incluir en la réplica. Cuando se crea una nueva réplica, se referencia al Leader y al log de transacción para saber que contenidos debe incluir. Si cae lo reintenta. Como el log de transacción consisten en un registro de las actualizaciones, permite un índice más robusto porque permite rehacer lo cambios que no se guardado si el índice se interrumpe. Cada leader y replica tiene su propio archivo de log, también se le llama tlog, y se crea en directorio de los datos.

Solr añade todos los documentos al final del log transaccional y se reescribe en cada hard commit. Cuando la solicitud es de un update atómico, se escriben en el tlog el valor anterior y el actual, lo que permite hacer un roll back. Si el commit se después de mucho tiempo o los documentos se indexan a gran velocidad, los ficheros pueden crecer mucho y la recuperación puede ser costosa.

Si se cae un leader, puede que se mande a algunas réplicas y no a otras, así que cuando un nuevo líder potencial es identificado, se corre un proceso de sincronía contra las otras replicas, Si es correcta todo tiene que ser consistente, el líder se registra como activo y se continua con las labores normales. Si la réplica no es capaz de sincronizarse el sistema pregunta por un recovery completo. Si las actualizaciones fallan porque los cores están re balanceando los esquemas y algunos han terminado y otros no, el leader les dice a los nodos que la actualización ha fallado y comience el procedimiento de recovery.

 

1.7          SolrCloud and Replication

La replicación asegura la redundancia de los datos y permite mandar un update a cualquier nodo del shard. Si ese nodo es una réplica, desviará la solicitud al leader, quien lo re direccionará a todas las réplicas existente, utilizando el versionado para asegurarse que cada replica tiene la versión más actualizada. Está arquitectura permite asegurar los datos en caso de desastre.

1.8          ZOOKEPER

Para que se utiliza zookeper:

  • Elección del Leader.
  • Administrar los ficheros de configuración:

Todos los ficheros de configuración dentro del directorio core/conf incluido el solrconfig.xml y el schema.xml, se mantiene en zookeper. Los nodos llaman a ZooKeeper para toda la configuración. Cualquier cambio se tiene que subir a zookeeper.

  • Planificar las rutas de las solicitudes de indexación o búsqueda.

ZooKeeper mantiene información del cluster, de sus colecciones de los nodos levantados, de los estados de la réplica, los cuales se revisan para la coordinación del cluster.

 

Son necesario un número impares de servidores de ZooKeeper. Para poder determinar la mayoría. Cuantos más servidores de zookeper tengamos más estabilidad tendremos. La mitad + 1 de los servidores de zookeper corriendo se le denomina quorum, si no hay quorum podremos hacer búsquedas, pero la indexación fallará.

 

Si no tienes suficiente quorum (la mita + 1) funcionará la búsqueda, pero fallará la indexación.

1.8.1         Utilizar ZooKeeper para controlar los archivos de configuración.

Con SolrCloud tus archivos de configuración se almacenan en ZooKeeper. Estos archivos se suben en los siguientes casos:

Cuando se inicia SolrCloud utilizando el script bin/solr script.

Cuando se crea una colección utilizando el script bin/solr script.

Cuando explícitamente la subimos ZooKeeper, con zkcli.sh

1.9          SolrCloud with Legacy Configuration Files

Cambios necesarios en los ficheros de configuracion para el modo SolrCloud.

  1. En schema.xml, se tiene que tener un campo _version_ definido:

<field name=”_version_” type=”long” indexed=”true” stored=”true”

multiValued=”false”/>

  1. En solrconfig.xml, se tiene que tener definido UpdateLog. Se define en la sección updateHandler

.

Apache Solr Reference Guide 5.5 572

<updateHandler>

<updateLog>

<str name=”dir”>${solr.data.dir:}</str>

</updateLog>

</updateHandler>

 

 

Sincronización en mongodb

Cuando un secundario opera de forma normal, elige un miembro conque sincronizarse y empieza a coger las operaciones de la colección local.oplog.rs . Cuando coge un una op hace los siguientes pasos:

  1. Aplica el op
  2. Escribe el op es su propio oplog (también oplog.rs)
  3. Solicita el siguiente op

Si la base de datos se cae entre el 1 y el 2, cuando se recupera piensa que no la ha hecho y lo vuelve a repetir. Lo hace de tal manera que se puede reaplicar.

Por ejemplo en un document como este {counter:1} si se hace algo así {$inc:{counter:1}} el documento se convertiría en algo así {counter:2} y en el oplog se almacena algo así {$set:{counter:2}}. Que es lo que se replicara a los secundarios.

  • w

Para asegurarnos que un cando está presente en los dos nodos utilizamos aslgo así:

> db.foo.runCommand({getLastError:1, w:2})

La sintaxis varia en función del lenguaje, pero lo que hace es asegurarse que este escrito en ambos nodos.

  1. Escribe en el primario.
  2. La escritura se escribe en el oplog del primario, con un campo ts que indica que la escrituta se a producido en tiempo t.
  3. {getLastError:1,w:2} se llama desde el primario, este ha haecho la escritura, pero le queda otro nodo w:2.
  4. El secundarioconsulta el oplog del primario para obtener el op
  5. El secundarioaplica el op desde el momento t
  6. El secundario pide las ops con {ts:{$gt:t}}al oplog del primario.
  7. El primarioactualiza que el secondario ha aplicado hasta has  t, porque está pidiendo ops > t.
  8. getLastError se da cuenta que ha sido actualizado en ambos nodos, así que w:2 se cumple y da por buena la inserción.
  • Starting up

Cuando se reinicia un nodo, revisa la colección local.oplog.rs para ver la última entrada. Esto se llama lastOpTimeWritten y es la última op que el secundario ha aplicado.

Para obtener está información via shell se puede utilizar el comando:

> rs.debug.getLastOpWritten()

El campo “ts” es el último optime escrito.

Si el miembro se reinicia y no hay entradas en el oplog, se iniciara un poceso de sincronía incial.

  • Con quien se sincroniza

Los servidores se sincronizan con el servidor más cercano en función de una media en el tiempo de respuesta de los servidores que están al día (sanos).

Se puede ver desde que servidor se sincroniza desde corriendo el comando db.adminCommand({replSetGetStatus:1}) y buscando el campo “syncingTo” (solamente presente en los secundarios).

  • Cambio de la sincronizacion…

La opción replSetSyncFrom, permite cambiar desde que miembro te quieres resincronizar.

> db.adminCommand({replSetSyncFrom:”otherHost:27017″})

 

Fuente:

 

https://dzone.com/articles/get-familiar-mongodb-replica

 

Actualizaciones sobre un índice ya creado con información de un archivo CSV

Teníamos que actualizar un índice que teníamos en solr con el valor de un campo que nos pasaban en un archivo CSV.

Ejemplo del archivo (el primer campo se corresponde identificador único en el índice) :

"36721373_934",1

"36719138_56",5

"36719199_58",7

"36719523_338",8

"36732719_16",9

"36720095_743",10

"36732723_757",11

"36721134_877",12

"36719244_1623",13

"36719244_118",14

 

Lo que hemos hecho es añadir un campo a squema.xml

<field name="prueba" type="int" indexed="true" stored="true" omitNorms="true"/>

Añadir la request handler de update en el solrconfig.xml

<requestHandler name="/update" class="solr.UpdateRequestHandler">

</requestHandler>

Y finalmente utilizar un curl de este estilo para actualizarlo.

http://xx.xx.xx.xxxx:xxxx/core1/update?stream.file=/path/prueba.csv&stream.contentType=text/csv;charset=utf-8&fieldnames=uid,prueba

spawn

Hoy me encontrado un pequeño problema, estaba ejecutando el sqldeveloper de manera remota y me preguntaba por unos passwords (ya sé que la manera más fácil es guardar los passwords en la conexión, pero por un pequeño error esto era imposible ver https://cajondesastreoracle.wordpress.com/2016/12/25/severe-java-sql-sqlrecoverableexception-io-error-connection-reset-linux-system/) así que hasta encontrar la solución definitiva estuve intentando el pasarle los passwords de manera dinámica con spawn.

Esta era la salida de la ejecución:

./sdcli unittest -run -suite -name "repos_prueba_suit" -repo "repos_owner" -db "repos_prueba"
 Oracle SQL Developer
 Copyright (c) 1997, 2015, Oracle and/or its affiliates. All rights reserved.

Password for repos_owner?

Password for repos_prueba?

Command Completed.

 

Esta es la forma de poder pasarle los passwords desde un scripts.

#!/usr/bin/expect -d

cd /opt/app/sqldeveloper/sqldeveloper/sqldeveloper/bin

log_user 1

set timeout -1

set PasswordOwner "repos_owner"

set PasswordUser "repos_prueba"

spawn ./sdcli unittest -run -suite -name "repos_prueba_suit" -repo "repos_owner" -db "repos_prueba"

expect "Password for repos_owner?"

send -- "$PasswordOwner\r"

expect -exact "Password for repos_prueba?"

send -- "$PasswordUser\r"

expect "Command Completed."

spawn ./sdcli reports generate -report "junit_suite_report" -db "repos_owner" -file "/home/hudson/REPORT_SUIT" -bind "suite_name=repos_prueba_suit"

expect "Password for repos_owner?"

send -- "$PasswordOwner\r"

expect "Command Completed.

Cómo hacer un volcado de información toda la información en memcached

A partir de la versión Memcached 1.4.31, se añade una nueva funcionalidad que permite dump de todosl los metadata de un slab class particular, una lista de slab clases o todos los slabs. Para poder hacer esto existe el comando lru_crawler metadump [all|1|2|3], para ejecutarlo desde el telnet.

https://github.com/memcached/memcached/pull/193

Para poder redireccionar la salida a un fichero hemos encontrado la opción de utilizar el comando tee:

 

telnet  ip puerto | tee -a log.log

#Almacenamos la clave.

set key 0 900 4

STORED

#Sacamos toda la información que está en la mmechached

lru_crawler metadump all

key=key exp=1483978211 la=1483977314 cas=1 fetch=no

quit

 

 

SEVERE java.sql.SQLRecoverableException: IO Error: Connection reset – Linux system

Después de varios días volviéndonos locos y de sufrir con dos síntomas, por un lado, cuando creábamos una conexión en sqldeveloper aunque le pedíamos que guardara el password no lo hacía y con errores intermitentes de java, con timeout en las conexiones, Descubrimos que hay un problema con los poles de generación número aleatorios en las máquinas virtuales. Esto se puede solucionar instalando y levantando haveged que permite generar de manera más rápida los números random,con esto se acelera la generación de llaves SSL y hace la encriptación más efectiva.

Según Oracle cuando hay una diferencia muy grnade entre el número de estos dos ficheros, siendo mucho menor el segundo:

$ cat /proc/sys/kernel/random/poolsize

$ cat /proc/sys/kernel/random/entropy_avail

Puede haber problemas que se solucionan instalando y levantando havenged.

 

# yum install haveged

# systemctl start haveged

# systemctl enable haveged