Fragmentos y réplicas en Elasticsearch

Intentaré explicarte con un ejemplo real ya que la respuesta y las respuestas que obtuviste no parecen ayudarte.

Cuando descarga elasticsearch y lo inicia, crea un nodo de elasticsearch que intenta unirse a un clúster existente si está disponible o crea uno nuevo. Supongamos que creó su propio clúster nuevo con un solo nodo, el que acaba de iniciar. No tenemos datos, por lo tanto necesitamos crear un índice.

Cuando crea un índice (un índice también se crea automáticamente cuando indexa el primer documento), puede definir de cuántos fragmentos estará compuesto. Si no especifica un número, tendrá el número predeterminado de fragmentos: 5 primarios. ¿Qué significa?

Significa que elasticsearch creará 5 fragmentos principales que contendrán sus datos:

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

Cada vez que indexe un documento, elasticsearch decidirá qué fragmento principal debe contener ese documento y lo indexará allí. Los fragmentos primarios no son una copia de los datos, ¡son los datos! Tener varios fragmentos ayuda a aprovechar el procesamiento paralelo en una sola máquina, pero el punto es que si iniciamos otra instancia de elasticsearch en el mismo clúster, los fragmentos se distribuirán de manera uniforme en el clúster.

El nodo 1 contendrá, por ejemplo, solo tres fragmentos:

 ____    ____    ____ 
| 1  |  | 2  |  | 3  |
|____|  |____|  |____|

Dado que los dos fragmentos restantes se movieron al nodo recién iniciado:

 ____    ____
| 4  |  | 5  |
|____|  |____|

¿Por qué pasó esto? Porque elasticsearch es un motor de búsqueda distribuido y de esta manera puede utilizar múltiples nodos/máquinas para administrar grandes cantidades de datos.

Cada índice de elasticsearch se compone de al menos un fragmento primario, ya que ahí es donde se almacenan los datos. Sin embargo, cada fragmento tiene un costo; por lo tanto, si tiene un solo nodo y no hay un crecimiento previsible, quédese con un único fragmento primario.

Otro tipo de fragmento es una réplica. El valor predeterminado es 1, lo que significa que cada fragmento principal se copiará a otro fragmento que contendrá los mismos datos. Las réplicas se utilizan para aumentar el rendimiento de la búsqueda y para la conmutación por error. Nunca se asignará un fragmento de réplica en el mismo nodo donde está el principal relacionado (sería más o menos como colocar una copia de seguridad en el mismo disco que los datos originales).

Volviendo a nuestro ejemplo, con 1 réplica tendremos el índice completo en cada nodo, ya que se asignarán 2 fragmentos de réplica en el primer nodo y contendrán exactamente los mismos datos que los fragmentos primarios en el segundo nodo:

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4R |  | 5R |
|____|  |____|  |____|  |____|  |____|

Lo mismo ocurre con el segundo nodo, que contendrá una copia de los fragmentos primarios del primer nodo:

 ____    ____    ____    ____    ____
| 1R |  | 2R |  | 3R |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

Con una configuración como esta, si un nodo deja de funcionar, aún tendrá el índice completo. Los fragmentos de réplica se convertirán automáticamente en primarios y el clúster funcionará correctamente a pesar del fallo del nodo, de la siguiente manera:

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

Como lo hizo "number_of_replicas":1, las réplicas ya no se pueden asignar ya que nunca se asignan en el mismo nodo donde está su principal. Es por eso que tendrá 5 fragmentos sin asignar, las réplicas y el estado del clúster será YELLOWen lugar de GREEN. No se pierden datos, pero podría ser mejor ya que algunos fragmentos no se pueden asignar.

Tan pronto como se haga una copia de seguridad del nodo que se había ido, se unirá nuevamente al clúster y las réplicas se asignarán nuevamente. El fragmento existente en el segundo nodo se puede cargar, pero es necesario sincronizarlo con los otros fragmentos, ya que las operaciones de escritura probablemente ocurrieron mientras el nodo estaba inactivo. Al final de esta operación, el estado del clúster será GREEN.

Espero que esto te aclare las cosas.

Mar 29 '2013 15:03 javanna