Expériences avec les pierres tombales dans Apache Cassandra

Détecter et prévenir les pierres tombales

Les pierres tombales peuvent être détectées dans les journaux et en surveillant des métriques spécifiques. Leur durée de vie est définie par le paramètre de table gc_grace_seconds.

Régler les paramètres de la table

• gc_grace_seconds

Le paramètre par défaut pour gc_grace_seconds est 864000 (10 jours). Pour nous, il était logique d’abaisser cette valeur à 345600 (4 jours). Si vous décidez de modifier le délai de grâce, assurez-vous d’effectuer les réparations dans ce délai.

Vous pouvez simplement modifier la valeur des tables existantes ou créer une nouvelle table comme celle-ci:

CRÉER un espace de clés de TABLE.nom de table AVEC GC_GRACE_SECONDS = 345600;

MODIFIER l’espace de clés de LA TABLE.nom de table AVEC GC_GRACE_SECONDS = 345600;

• TTL

Une fois que TTL a dépassé la plage de temps définie, les lignes sont supprimées et les valeurs sont transformées en pierres tombales. Par défaut, les lignes/valeurs n’expirent pas.

En rencontrant les problèmes de pierre tombale, nous avons compris que nous devions augmenter le temps de vie de nos tables. En ayant cette valeur définie sur 1 ½ jour, l’échec des travaux d’ÉCRITURE a eu pour effet de supprimer toutes les données d’une table à la fois. En raison des mises à jour manquantes, chaque ligne était marquée d’une pierre tombale. Fixer la valeur plus élevée nous permet de relancer les travaux à temps et d’éviter la création inutile d’une grande quantité de pierres tombales.

• tombstone_warn_threshold

L’avertissement de seuil de pierre tombale est défini sur 1.000 par défaut et il deviendra visible dans vos journaux au cas où plus de 1.000 pierres tombales seraient analysées par une seule requête.

• tombstone_failure_threshold

Le seuil de défaillance de la pierre tombale est atteint lorsque 100 000 pierres tombales sont analysées par une seule requête. Dans ce cas, la requête sera abandonnée, ce qui signifie que les données de la table affectée ne peuvent plus être interrogées.

Ces paramètres de seuil peuvent être modifiés, mais sachez que si vous les augmentez, cela peut entraîner un manque de mémoire des nœuds.

Effectuer des réparations régulières

Cassandra est livré avec une tolérance aux pannes élevée et fonctionne bien même si un nœud est temporairement indisponible. Néanmoins, il est recommandé d’exécuter nodetool repair après une défaillance d’un nœud. Surtout si vous voulez éviter à tout prix la perte de données.

Pendant le processus de réparation, le nœud indisponible recevra les écritures qui se sont produites pendant son temps d’arrêt.

C’est une bonne approche pour exécuter des réparations dans les secondes gc_grace_seconds et régulièrement, sinon vous risquez de rencontrer des cas où des données supprimées sont ressuscitées.

Il existe plusieurs façons d’exécuter les réparations automatiquement. L’un d’eux est Cassandra Reaper. Cet outil est livré avec une interface utilisateur agréable qui facilite la planification des réparations.

Configurez et exécutez le compactage

Pour supprimer enfin les pierres tombales et libérer de l’espace disque, le compactage doit être déclenché. Il existe différents types de compactions. Le compactage mineur exécute le compactage sur toutes les tables sstables et s’exécute automatiquement dans Cassandra. Il supprime toutes les pierres tombales qui sont plus anciennes que la période de grâce. Si vous déclenchez un compactage manuellement sur toutes les tables sstables, cela s’appelle un compactage majeur. Gardez à l’esprit que le compactage doit être déclenché pour chaque nœud individuellement. Vous avez également la possibilité d’exécuter un compactage défini par l’utilisateur uniquement sur un groupe de tables sstables spécifiées.

Compacter des données en C* signifie généralement fusionner des tables sstables en une seule nouvelle table sstable. Lorsque vous effectuez des lectures sur plusieurs lignes, plus il y a de tables sstables à analyser, plus le processus est lent. Pour éviter que cela ne se produise, le compactage doit fonctionner régulièrement.

Pour démarrer les compactions manuellement, vous pouvez utiliser nodetool compact. Si vous ne spécifiez pas d’espace de clés ou de table, le compactage s’exécutera sur tous les espaces de clés et tables.

nom de table nodetool compact keyspace

Cette commande démarre un compactage sur la table spécifiée. Vous devez déterminer quelle stratégie de compactage est configurée pour vos tables et la comparer avec les stratégies alternatives. Si vous souhaitez savoir si une autre stratégie répond mieux à vos besoins, vous pouvez consulter la documentation DataStax.

Mesures de la table de surveillance

1. Nodetool

Nodetool est l’interface de ligne de commande de Cassandra. Il est utile si vous souhaitez en savoir plus sur les performances de vos clusters. Vous pouvez consulter la liste complète des commandes possibles fournies par DataStax.

Les commandes Nodetool doivent être exécutées individuellement pour chaque nœud. Nous exécutons C * sur Kubernetes afin que nous puissions ouvrir un shell pour le pod Cassandra en cours d’exécution comme suit:

kubectl exec-it cassandra-0-n recommande bash

À partir de ce moment, nous pouvons utiliser nodetool pour obtenir diverses informations sur nos tables. La commande nodetool tablestats peut être exécutée pour imprimer des statistiques pour des espaces de clés ou des tables individuels:

Les valeurs de “Pierres tombales moyennes par tranche ” et de “Pierres tombales maximales par tranche ” vous indiqueront le nombre de pierres tombales scannées par requête au cours des cinq dernières minutes. Si vous voyez que cette valeur est très élevée, vous devrez peut-être exécuter le compactage plus souvent pour cette table.

2. Outils SSTable

Avant d’exécuter les outils SSTABLE, Cassandra doit être arrêtée. La commande sstableutil vous donnera une liste des fichiers sstable existants pour une certaine table. L’exécution de sstablemetadata sur ces fichiers vous fournira des informations utiles sur la table spécifiée, comme par exemple le TTL et une estimation des pierres tombales tombables.

3. Prométhée et Grafana

Notre monitoring pour C* est mis en place avec Prométhée et Grafana. Après avoir reçu les avertissements de seuil des pierres tombales, nous avons décidé d’ajouter un panneau à notre tableau de bord qui nous donne une idée du comportement des pierres tombales pour chacune de nos tables.

Cassandra a une métrique de table appelée ‘TombstoneScannedHistogram’, qui présente l’histogramme des pierres tombales analysées par requête. En montrant le 99e centile, nous verrons si quelque chose ne va pas.