En general, un clúster bien diseñado puede vivir AÑOS sin ser tocado. He tenido grupos que se ejecutaron durante años sin intervención. Sin embargo, aquí hay algunas pautas:
El monitoreo es muy importante:
1) Monitorizar latencias. Utilice opscenter o sus herramientas de métricas favoritas para realizar un seguimiento de las latencias. Las latencias que aumentan pueden ser signos de problemas, incluidas las pausas de GC (más comunes en las cargas de trabajo de lectura que en las cargas de trabajo de escritura), problemas estables y similares.
2) Monitorear recuentos estables. Los recuentos de SSTable aumentarán si se sobrepasa la compactación (cada inestable se escribe exactamente una vez; las eliminaciones se manejan combinando inestables antiguos en inestables nuevos mediante la compactación).
3) Supervisar los cambios de estado del nodo (arriba / abajo, etc.). Si ve aleteo de nodos, investigue, ya que no es normal.
4) Realice un seguimiento del uso de su disco: tradicionalmente, debe mantenerse por debajo del 50% (especialmente si usa compactación STCS).
Hay algunas cosas básicas que debes y no debes hacer regularmente:
1) No corras explícitamente nodetool compact. Menciona que lo ha hecho, no es fatal, pero crea inestables muy grandes, que luego son menos propensos a participar en la compactación en el futuro. No necesariamente necesita seguir ejecutándolo, pero a veces puede ayudar deshacerse de los datos eliminados / sobrescritos.
2) nodetool repairgeneralmente se recomienda cada gc_grace_seconds(10 días por defecto). Hay cargas de trabajo donde esto es menos importante: la razón principal por la que NECESITA reparación es para asegurarse de que los marcadores de eliminación ( tombstones) se transmitan antes de que caduquen (viven gc_grace_seconds, si un nodo está inactivo cuando ocurrió la eliminación, esos datos pueden volver a la vida sin la reparación! Si no emite eliminaciones y consulta con un nivel de consistencia suficiente (por ejemplo, lecturas y escrituras en QUORUM), puede vivir una vida sin reparación.
3) Si va a reparar, considere usar una reparación incremental y repare rangos pequeños a la vez.
4) Las estrategias de compactación son importantes. STCS es ideal para escrituras, LCS es ideal para lecturas. DTCS tiene algunas peculiaridades.
5) Los modelos de datos son importantes: al igual que los entornos RDBMS / SQL se meten en problemas cuando las consultas no indexadas llegan a tablas grandes, Cassandra puede ser problemática con filas / particiones muy grandes.
6) Las instantáneas son baratas. Muy barato. Casi instantáneamente, solo enlaces duros, casi no cuestan espacio en el disco de inmediato. Utilice la instantánea antes de actualizar las versiones, especialmente las versiones principales.
7) Tenga cuidado con los borrados. Como se insinuó en el n. ° 2, eliminar crea más datos en el disco y no los libera AL MENOS gc_grace_seconds.
Cuando todo lo demás falla:
He visto artículos que sugieren que Cassandra en producción requiere una cabeza dedicada para administrar cualquier clúster de tamaño; no sé si sea necesariamente cierto, pero si le preocupa, puede contratar a un consultor externo (TheLastPickle, Pythian). ) o tener un contrato de soporte (Datastax) para darle tranquilidad.