Lorsqu’un nœud est injoignable/absent d’un cluster Cassandra, il convient d’investiguer sur la raison de cette indisponibilité afin de connaître la raison pour la prévenir ou résoudre l’erreur en découlant.
On peut regarder plusieurs points tels que :
- Log d’erreur
- Log de debug
- Log du garbage collector
- Analyse des graphiques si vous avez un outil d’analyse ou une supervision
- Utiliser les utilitaires nodetool
- Analyse réseau
- Vérification de l’uptime
- Vérification de la log système
- …
Une fois l’erreur identifiée, il faut convenir d’un mécanisme de réparation approprié. Par exemple si un nœud est absent du cluster pour un problème réseau ou le serveur/Cassandra était OFF (perte d’ESX, erreur humaine, …), il y a trois cas possibles de réparation possible.
Votre nœud est absent du cluster pour une durée inférieure à 3h (si le paramètre par défaut : max_hint_window_in_ms n’a pas été modifié)
Dans ce cas-là, une fois que le nœud a rejoint le cluster, le mécanisme de Hinted Handoff va rejouer toutes les modifications stockées dans le fichier de hints. A la fin de cette opération, le nœud aura ses données à jour.
Rappel : Mécanisme Hinted Handoff
Un client souhaite écrire des données, il envoie sa requête au nœud coordinateur qui au vu de la répartition des données sur le cluster veut écrire sur le nœud C malheureusement celui-ci est indisponible.
Dans ce cas-là le nœud coordinateur va écrire temporairement (pour une durée de 3h par défaut, à configurer dans le cassandra.yaml) la requête K du client en local dans un fichier (à partir de la version 3.0).
Lorsque le nœud C rejoindra le cluster, le nœud A lui transmettra les données, ainsi le nœud C n’aura pas besoin d’être réparé.
Plus d’explications sur le mécanisme de Hinted Handoff : https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsRepairNodesHintedHandoff.html
Pour s’assurer le bon déroulement du mécanisme de Hinted Handoff, il faut surveiller les logs de Cassandra, afin de détecter de potentielles problématiques au niveau du streaming. Si c’est le cas, il faudra réparer la table.
Attention tant que le mécanisme de Hinted Handoff n’est pas achevé, le noeud restera dans un état incohérent. Les réponses fournies au client seront donc potentiellement incomplètes.
Votre nœud est absent du cluster pour une durée supérieure à 3h (si le paramètre par défaut : max_hint_window_in_ms n’a pas été modifié)
Dans ce cas-là, une fois que le nœud a rejoint le cluster il faut faire un repair pour resynchroniser le nœud. Si jamais le nœud reçoit des requêtes de lecture pendant la réparation, les résultats seront potentiellement datés, incomplets ou vides.
Pour éviter cet impact, il est utile d’avoir un deuxième datacenter pour faire basculer tous le client sur celui et faire les manipulations (repair/rebuild) sur le nœud en question.
Votre nœud est absent depuis x semaine(s)/mois
Si le nœud est absent depuis une durée assez importante, nous allons préférer faire un remplacement (paramètre : -Dcassandra.replace_address) pour éviter d’échanger les tokens plutôt que faire un décommissionnement puis un ajout. Au-delà de la question des perfs, si le nœud était down depuis plus de gc_grace_seconds, cette méthode permettra aussi d’éviter la réapparition de lignes supprimées.
Pendant cette opération le status de nœud est DOWN, il est donc important que le replacement se termine avant le max_hint_window_in_ms.
Si vous souhaitez une formation ou un support technique sur Cassandra, n’hésitez pas à nous contacter.