Cúmulo de Cassandra desequilibrado

cassandra-cli nodetool

Question

Actualización - Versión corta:
PropertyFileSnitch cassandra-topology.properties para los primeros 3 nodos (Rack 1-3) establece que solo estos nodos están en DC1 y los otros están en DC2 al especificar el valor default=DC2:r1 . Cuando el clúster se amplió agregando nodos 4 y 5, el PropertyFileSnitch para estos nodos se configuró para agregarlos en DC1 también en Rack 4 y 5, pero la snitch de los primeros 3 nodos permaneció sin cambios y como resultado el clúster se encuentra en este estado inconsistente.

Mi pregunta es si este grupo puede reequilibrarse (arreglarse). ¿Sería suficiente si hiciera un reinicio completo del clúster después de corregir las cassandra-topology.properties ?
Por favor asesórese sobre cómo puedo reequilibrar de manera segura el clúster.

Versión más larga:

Soy nuevo en Cassandra y comencé a trabajar en un clúster ya creado.
Tengo 5 nodos en el mismo centro de datos en diferentes bastidores que ejecutan Cassandra versión 3.0.5 con vnodes num_tokens: 256 y un espacio de claves con replication = {''class'': ''NetworkTopologyStrategy'', ''DC1'': ''3''} AND durable_writes = true .
Históricamente, solo había 3 nodos y el clúster se amplió con otros 2 nodos. Tengo un script de reparación automática que ejecuta la nodetool repair con parallelism: parallel, primary range: false, incremental: true, job threads: 1 opciones parallelism: parallel, primary range: false, incremental: true, job threads: 1 .

Después de insertar una gran cantidad de datos, los problemas comenzaron a aparecer. Al ejecutar el script de reparación en el nodo 4 o 5, el nodo 2 se sobrecarga: el uso de la CPU se mantiene al 100%, la cola MutationStage crece y las pausas del GC tardan al menos 1 hasta que el proceso de Cassandra finalmente muere. El resultado de la reparación suele failed with error Stream failed (progress: 0%) .

Cuando nodetool status comando nodetool status en los nodos 1, 2 o 3 obtengo el siguiente resultado: Datacenter: DC2 Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.0.13 10.68 GB 256 0.0% 75e17b8a r1 UN 10.0.0.14 9.43 GB 256 0.0% 21678ddb r1 Datacenter: DC1 Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.0.10 16.14 GB 256 100.0% cf9d327f Rack1 UN 10.0.0.11 22.83 GB 256 100.0% e725441e Rack2 UN 10.0.0.12 19.66 GB 256 100.0% 95b5c8e3 Rack3

Pero cuando nodetool status comando nodetool status en los nodos 4 o 5 obtengo el siguiente resultado: Datacenter: DC1 Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.0.13 10.68 GB 256 58.9% 75e17b8a Rack4 UN 10.0.0.14 9.43 GB 256 61.1% 21678ddb Rack5 UN 10.0.0.10 16.14 GB 256 60.3% cf9d327f Rack1 UN 10.0.0.11 22.83 GB 256 61.4% e725441e Rack2 UN 10.0.0.12 19.66 GB 256 58.3% 95b5c8e3 Rack3

Tras una investigación más exhaustiva, parece que PropertyFileSnitch cassandra-topology.properties no se actualizó en los nodos 1, 2 y 3 (que también son las semillas de este clúster) después de que se amplió el clúster.

¡Gracias!

Answer 1

No puedo decir si lo que sugirió es suficiente sin acceder al sistema, pero tengo algunas observaciones. La propiedad debe distribuirse entre todos los nodos del clúster. Esto significa que el total de todos los valores en la pestaña "Propietario" para los 5 nodos debe ser igual a 100 si están formando un clúster. Tener varios nodos que poseen el 100% del clúster no se ve bien. Esto indica que cada nodo está actuando en modo independiente y no está unido al clúster.
Veo la dirección 10.40.0.10 en la primera impresión mientras que es 10.0.0.10 en la segunda impresión. Parece una mala configuración. Además, verifique si cada nodo puede llegar a todas las direcciones IP de otros nodos. Veo que 10.0.0.13 pertenece a ''r1'' en la primera impresión, mientras que pertenece a ''Rack4'' en la segunda.
Para simplificar y facilitar la configuración, puede configurar un centro de datos (por ejemplo, DC1) y un rack (por ejemplo, Rack1) para los 5 nodos, independientemente de su distribución física.

Answer 2

Después de buscar en varios recursos en línea encontré algunas soluciones posibles. Los publicaré aquí para que todos puedan acceder.

De Practical Cassandra: El enfoque de un desarrollador :

Ring View difiere entre nodos
Cuando la vista de anillo difiere entre nodos, nunca es algo bueno. Tampoco hay una manera fácil de recuperarse de este estado. La única forma de recuperar es hacer un reinicio completo del clúster. Un reinicio continuo no funcionará porque el protocolo Gossip de los nodos incorrectos informará a los nodos buenos de nuevo arranque del estado incorrecto. Un reinicio completo del clúster y poner los nodos en buen estado primero debería permitir que el clúster regrese en buen estado.

La misma solución se puede encontrar también en documentos de DataStax : la vista del anillo difiere entre algunos nodos

También encontré una pregunta similar sobre Apache Cassandra Community . La respuesta en el hilo de los usuarios de la comunidad es:

Lo que sucedió es que ahora tiene dos centros de datos en su clúster. La forma en que replican la información dependerá de la configuración de tu espacio de claves. En cuanto a su proceso, no creo que sea seguro hacerlo de esa manera. Comenzaría desmantelando los nodos 4 y 5 para que su clúster vuelva a 1 centro de datos con 3 nodos y luego los vuelva a agregar secuencialmente, asegurándose de que la configuración en la Snitch sea la correcta.