Problema de replicación de datos de Cassandra

Question

Tengo un clúster Cassandra de 2 nodos con un factor de replicación de 2 y AutoBootStrap = verdadero. Todo está bien durante el inicio y ambos nodos se ven entre sí. Llamemos a estos nodos A y B.

1. Añadir un juego de llaves y columnas (permite llamar a este conjunto K1) a Cassandra a través del nodo A.
2. Conectar al nodo A y leer conjunto posterior K1. Lo mismo en el nodo B. Éxito - Buena
3. Terminar proceso Cassandra en el nodo B.
4. agregue el conjunto a través de K2 A.
5. Conectar al nodo A y Lectura del registro K2. Bueno
6. Reinicie el proceso de Cassandra en el Nodo B.
7. Intente leer todas las claves de B ... configure K1 presente, establezca K2 DESAPARECIDO. (Incluso después de 30 minutos)
8. Agregue K3 a A/B.
9. Leer todas las claves de A - devuelve K1, K2, K3
10. Leer todas las claves de B - devuelve el conjunto K1, K3.

B nunca se sincroniza establece K2 ... (Han pasado más de 12 horas) ¿Por qué nodo B no vea SET K2 ... alguien tiene alguna idea?

---

Agregado Información:

Ok ... esto era el problema. read_consistency_level se estableció en 1 de manera predeterminada.

Entonces, cuando le preguntamos al nodo B por el conjunto K2, y no lo tiene (cuando se supone que debido al factor de replicación = 2), inmediatamente regresa con un error "No encontrado".

Sin embargo, si usamos la consistencia de lectura para ser QUORUM o TODO, entonces B se ve obligado a preguntar A, que luego devuelve el valor correcto y B sincroniza esa tecla (la guarda localmente).

Esto lleva a otro problema: esto significa que cuando aparece el nodo B, no está sincronizando todos los datos del Nodo A, incluso después de un largo tiempo. Ahora, si el nodo A falla, ¿cómo podemos acceder a esos datos sin sincronizar? (Acabo de probar que no podemos)

Supongo que debe haber una forma de forzar la sincronización de los datos. Veo el INFO en la salida del terminal que ocurrió un traspaso indirecto de 15 filas de A a B cuando B apareció, pero B no tiene esas filas localmente (porque todavía no podemos leerlo desde B con nivel de consistencia UNO). ¿Que está pasando aqui?

Answer 1

hay 3 formas Cassandra sincroniza cambios que ocurrieron mientras que un nodo estaba abajo:

1. insinuó traspaso. requiere que el detector de fallas en A reconozca que B está inactivo antes de escribir K2. Consulte http://wiki.apache.org/cassandra/HintedHandoff
2. lea la reparación. requiere que B esté activo cuando se solicita K2 para que se realice la reparación. Consulte http://wiki.apache.org/cassandra/ReadRepair
3. reparación de antientropía. requiere invocación manual ("reparación de nodetool"). ver http://wiki.apache.org/cassandra/AntiEntropy