En général, un cluster bien conçu peut vivre des ANNÉES sans être touché. J'ai eu des grappes qui ont fonctionné pendant des années sans intervention. Cependant, voici quelques directives:
La surveillance est extrêmement importante:
1) Surveillez les latences. Utilisez opscenter ou vos outils de mesure préférés pour suivre les latences. Les latences qui augmentent peuvent être des signes de problèmes à venir, y compris des pauses GC (plus courantes dans les charges de travail en lecture que dans les charges de travail en écriture), des problèmes instables, etc.
2) Surveillez les comptes stables. Le nombre de SSTables augmentera si vous dépassez le compactage (chaque sstable est écrite exactement une fois - les suppressions sont gérées en combinant d'anciennes sstables dans de nouvelles sstables via le compactage).
3) Surveiller les changements d'état des nœuds (haut / bas, etc.). Si vous voyez des nœuds battre, examinez, car ce n'est pas normal.
4) Gardez une trace de votre utilisation du disque - traditionnellement, vous devez rester inférieur à 50% (surtout si vous utilisez le compactage STCS).
Il y a certaines choses de base que vous devriez et ne devriez pas faire régulièrement:
1) Ne pas exécuter explicitement nodetool compact
. Vous mentionnez que vous l'avez fait, ce n'est pas fatal, mais cela crée de très grandes écuries, qui sont alors moins susceptibles de participer au compactage à l'avenir. Vous n'avez pas nécessairement besoin de continuer à l'exécuter, mais parfois cela peut aider à se débarrasser des données supprimées / écrasées.
2) nodetool repair
est généralement recommandé tous les gc_grace_seconds
(10 jours par défaut). Il y a des charges de travail où cela est moins important - la principale raison pour laquelle VOUS AVEZ BESOIN de réparation est de vous assurer que les marqueurs de suppression ( tombstones
) sont transmis avant leur expiration (ils survivent gc_grace_seconds
, si un nœud est arrêté lorsque la suppression s'est produite, que les données peuvent reprendre vie) sans la réparation!). Si vous n'effectuez pas de suppressions et que vous interrogez avec un niveau de cohérence suffisant (lectures et écritures sur QUORUM, par exemple), vous pouvez réellement vivre une vie sans réparation.
3) Si vous envisagez de réparer, envisagez d'utiliser la réparation incrémentielle et réparez de petites plages à la fois.
4) Les stratégies de compactage sont importantes. STCS est idéal pour les écritures, LCS est idéal pour les lectures. DTCS a quelques bizarreries.
5) Les modèles de données sont importants - tout comme les environnements RDBMS / SQL rencontrent des problèmes lorsque des requêtes non indexées atteignent de grandes tables, Cassandra peut être problématique avec de très grandes lignes / partitions.
6) Les instantanés sont bon marché. Vraiment pas cher. Presque instantanés, juste des liens durs, ils ne coûtent presque pas d'espace disque immédiatement. Utilisez l'instantané avant de mettre à niveau les versions, en particulier les versions majeures.
7) Soyez prudent avec les suppressions. Comme indiqué dans # 2, la suppression crée plus de données sur le disque et ne les libère PAS AU MOINS gc_grace_seconds
.
Quand tout le reste échoue:
J'ai vu des articles qui suggèrent que Cassandra in prod nécessite une tête dédiée pour gérer n'importe quel cluster de taille - je ne sais pas si c'est nécessairement vrai, mais si vous êtes inquiet, vous voudrez peut-être embaucher un consultant tiers (TheLastPickle, Pythian ) ou avoir un contrat de support (Datastax) pour vous donner une tranquillité d'esprit.