Verteilte Datenbanken wie Cassandra und ScyllaDB sind mittlerweile zentrale Komponenten moderner Dateninfrastrukturen. Sie ermöglichen skalierbare, fehlertolerante Speicherung und Verarbeitung großer Datenmengen. Trotz ihrer Stärken stehen sie jedoch vor der Herausforderung, gelöschte Daten zuverlässig zu entfernen und deren mögliche Rückkehr, die sogenannte Datenresurrection, zu verhindern. Ein kritischer Faktor dabei sind die Reparaturprozesse und die Einhaltung bestimmter Zeitvorgaben, insbesondere in Bezug auf die Garbage Collection Grace Period – auch bekannt als gc_grace_seconds. Um die Problematik besser zu verstehen, ist ein Grundverständnis des Löschvorgangs in Cassandra und Scylla essenziell. Wenn Daten gelöscht werden, verschwinden sie nicht sofort aus der Datenbank. Stattdessen werden sogenannte Tombstones angelegt, spezielle Marker, die signalisieren, dass die Daten gelöscht sind.
Diese Tombstones bleiben im System, bis sie im Rahmen von Kompaktierungsprozessen endgültig entfernt werden dürfen. Der Zeitraum, in dem Tombstones aufbewahrt werden, wird durch die Einstellung gc_grace_seconds definiert – eine Art Schonfrist, die standardmäßig oft auf 10 Tage gesetzt ist. Das Ziel dieser Schonfrist ist es, sicherzustellen, dass die Löschungsinformation (also der Tombstone) vollständig und konsistent auf alle Replikate verteilt ist, denn Cassandra und Scylla arbeiten mit einem eventual konsistenten Replikationsmodell. Die letzte Schreibentscheidung gilt, was bedeutet, dass eine Verzögerung oder ein Ausfall bei der Verteilung von Löschinformationen auf manchen Knoten dazu führen kann, dass sie einen Tombstone nicht kennen.
Wird ein Tombstone auf einem Knoten nach Ablauf von gc_grace_seconds entfernt, während andere Knoten ihn noch nicht erhalten haben, entsteht eine gefährliche Situation: Der Knoten ohne Tombstone hält die Daten für gültig und gibt sie bei einer Anfrage wieder zurück. Dadurch kommt es zur sogenannten Datenresurrection – gelöschte Daten tauchen fälschlicherweise wieder auf. Standardmechanismen wie Hints oder Read Repairs können zwar dabei helfen, Tombstones im Netzwerk zu verbreiten, garantieren jedoch keine komplette Konsistenz in allen Fällen. Nur eine explizite Reparatur – meist ausgeführt mit dem Werkzeug nodetool repair – stellt sicher, dass alle Replikate synchronisiert sind und sämtliche Tombstones verbreitet wurden, bevor ihre Schonfrist abläuft. Die Komplexität in der Praxis entsteht dadurch, wie Reparaturen auf Clusterebene gesteuert werden. Einzelne nodetool-repair-Operationen werden oft durch Werkzeuge wie Cassandra Reaper oder Scylla Manager orchestriert.
Diese sorgen etwa dafür, dass Reparaturen auf unterschiedlichen Knoten zeitlich gestaffelt ablaufen, um die Systemperformance nicht zu beeinträchtigen. Dabei ist die genaue Reihenfolge und der Zeitpunkt dieser Reparaturen jedoch nicht deterministisch und schwanken von Zyklus zu Zyklus. Die offizielle Dokumentation von Cassandra und Scylla empfiehlt daher, Reparaturen mindestens so häufig durchzuführen, dass der gc_grace_seconds-Zeitraum niemals überschritten wird. Konkret bedeutet dies, bei einer Standard-Setzung von 10 Tagen sollten alle Knoten mindestens einmal alle 7 Tage gereinigt werden, um ausreichend Pufferraum für Verzögerungen zu schaffen. Diese Empfehlung stellt zwar eine gute Orientierung dar, hat jedoch deutliche theoretische und praktische Schwächen. Zum einen berücksichtigt sie nicht, dass eine Reparatur mehrere Tage dauern kann.
Wenn beispielsweise eine Clusterreparatur 3 bis 4 Tage in Anspruch nimmt und erst dann eine neue beginnt, besteht die Gefahr, dass Tombstones erst nach Ablauf ihrer Schonfrist vollständig verarbeitet werden. Zum anderen können innerhalb eines Reparaturzyklus Daten in Tokens gelöscht werden, die aber erst im nächsten Reparaturlauf behandelt werden. Wenn dieser Prozess nicht innerhalb von gc_grace_seconds abgeschlossen wird, können ebenfalls Daten resurgieren. Diese zeitlichen Herausforderungen führen zu einer verschärften Anforderung an Reparaturzyklen: Um wirklich eine Datenresurrection zu verhindern, muss sichergestellt werden, dass zwei aufeinanderfolgende Reparaturen nicht länger als gc_grace_seconds vom Start der ersten bis zum Abschluss der zweiten dauern. Anders ausgedrückt: Die Zeitspanne vom Beginn der ersten Reparatur bis zum Ende der zweiten Reparatur muss kürzer sein als der Garbage Collection Grace Period Wert.
Dieses Konzept sorgt dafür, dass jeder Tombstone, der nach Beginn der ersten Reparatur entsteht, garantiert von der zweiten Reparatur abgedeckt wird, bevor seine Lebenszeit endet und er gelöscht wird. Dadurch wird die Situation ausgeschlossen, dass Daten aufgrund von fehlendem Tombstone neu auftauchen. In der Praxis sind diese Anforderungen jedoch oft schwer realisierbar. Cluster mit sehr großen Datenmengen und zahlreichen Knoten brauchen mehrere Tage für vollständige Reparaturläufe. Wartungsfenster, Cluster-Expansion oder andere Administrationsaufgaben können Reparaturen pausieren oder verzögern. Zudem ist eine zu häufige oder parallele Durchführung von Reparaturen riskant, da sie die Performance spürbar beeinträchtigen kann. Erweiternde Mechanismen wie die in der kommenden Cassandra-Version 5. 1 geplante Unified Repair Solution richten sich dabei an die Herausforderung, Reparaturbedarf besser priorisieren und überwachen zu können.
Insbesondere kann so sichergestellt werden, dass der am längsten nicht reparierte Knoten Vorrang erhält. Metriken wie LongestUnrepairedSec ermöglichen ein gezieltes Monitoring und dadurch ein effektiveres Management der Reparaturzyklen. Scylla verfolgt einen alternativen Lösungsweg mit der sogenannten Repair Based Tombstone Garbage Collection. Diese Technologie erlaubt es, Tombstones vor Ablauf von gc_grace_seconds bereits zu komprimieren, sofern klar ist, dass sie repariert wurden. Dadurch können längere Schonfristen gewählt werden, ohne dass die Performance erheblich leidet. Diese Option wird aktuell noch weiterentwickelt und bleibt optional. Eine andere Strategie zur Vermeidung von Datenresurrection ist die Verwendung eines Löschvorgangs mit der Konsistenzstufe ALL. Dabei garantiert das System, dass eine Löschung nur als erfolgreich gilt, wenn alle Replikate den Tombstone erhalten haben.
Diese Methode erhöht jedoch die Anforderungen an Verfügbarkeit und Stabilität des Clusters, da ein einziger ausgefallener Knoten Löschungen blockieren kann. Um dies zu umgehen, setzen einige Betreiber auf eine Kombination aus Löschungen mit QUORUM und einem nachgelagerten Synchronisierungsmechanismus, der sicherstellt, dass Tombstones schließlich doch auf alle Knoten propagiert werden. Letztlich ist die Verhinderung der Datenresurrection in Cassandra und Scylla ein komplexer Balanceakt zwischen Systemverfügbarkeit, Reparaturfrequenz, Clustergröße und Performance. Betreiber sollten die Reparaturintervalle sorgfältig basierend auf Größe, Last und Konfigurationsparametern planen. Dabei ist es ratsam, gc_grace_seconds nicht zu kurz zu setzen, um unnötige Belastungen durch häufige Reparaturen zu vermeiden, aber auch nicht so lang, dass unnötig viele Tombstones das System belasten. Das Monitoring und die Steuerung der Reparaturprozesse sind dabei von besonderer Bedeutung.
Moderne Tools und neue Datenbankfeatures bieten hier zunehmend bessere Möglichkeiten, um Risiken frühzeitig zu erkennen und proaktiv gegenzusteuern. Nur durch ein umfassendes Verständnis der zugrunde liegenden Zeitfenster und Abläufe lässt sich die Datenkonsistenz in verteilten Systemen langfristig sicherstellen. Fazit: Die Planung und Durchführung von Reparaturen in Cassandra und Scylla ist entscheidend, um das Risiko der Datenresurrection zu eliminieren. Dies erfordert, dass aufeinanderfolgende komplette Reparaturen innerhalb des Garbage Collection Grace Period Zeitraums liegen, um alle Tombstones zuverlässig zu propagieren. Nur so können gelöschte Daten tatsächlich dauerhaft entfernt werden. Betreiber sollten daher stets die Dauer und Intervalle ihrer Reparaturzyklen überwachen und anpassen, um Datenintegrität und Performance optimal in Einklang zu bringen.
