Usunięty rekord może „zmartwychwstać”, jeśli jedna replika nie dowie się o jego usunięciu
W rozproszonej bazie kasowanie danych też jest informacją, którą trzeba zreplikować. Cassandra nie może po prostu natychmiast wymazać rekordu z jednej maszyny, bo inna replika może być offline i nadal przechowywać starą wartość. Zamiast tego zapisuje tombstone — znacznik mówiący, że dane zostały usunięte. Jeżeli taki znacznik zostanie usunięty z działających replik, zanim długo odłączony węzeł wróci i zostanie naprawiony, stara kopia może zostać potraktowana jak żywa wersja i ponownie rozpowszechniona. Dokumentacja Cassandry nazywa taki rekord zombie.
Delete jest także zapisem
W bazie jednowęzłowej można myśleć o usunięciu jako o zniknięciu bajtów. W Cassandrze DELETE tworzy nową, timestampowaną informację — tombstone. Przechodzi ona ścieżką zapisu podobnie jak inne mutacje i musi dotrzeć do odpowiednich replik.
Dlaczego nie wystarczy brak rekordu
Wyobraźmy sobie replikę A bez rekordu i replikę B zawierającą wartość sprzed tygodnia. Czy A nigdy tego rekordu nie miała, czy został świadomie usunięty? Sam brak danych nie niesie historii. Tombstone odpowiada: „ten rekord istniał, ale później został skasowany”.
Problem pojawia się przy długiej awarii
Jeśli B jest offline podczas kasowania, nie dostaje tombstone'a. Pozostałe repliki przez pewien okres zachowują znacznik, aby dać B czas na powrót i repair. Po upływie grace period tombstone może zostać fizycznie usunięty podczas compaction.
Tak rodzi się zombie
Jeżeli stary węzeł wróci dopiero po zniknięciu tombstone'a i nie zostanie odpowiednio naprawiony, może posiadać jedyną zachowaną kopię dawnej wartości. System może wtedy potraktować ją jak dane, które należy znowu rozpropagować. Dokumentacja DataStax i Apache Cassandra opisuje właśnie takie „resurrected data” jako zombie.
Usuwanie jest trudniejsze, niż wygląda
Mechanizm tombstone pokazuje głębszą zasadę systemów rozproszonych: negatywna informacja także wymaga trwałej reprezentacji. „Nie ma X” jest niewystarczające, jeśli inne węzły mogą nadal pamiętać X. Aby bezpiecznie zapomnieć fakt o usunięciu, trzeba najpierw mieć wystarczającą pewność, że wszystkie istotne kopie również się o nim dowiedziały.
Tombstone sam może stać się problemem wydajnościowym
Znaczniki usunięcia muszą żyć wystarczająco długo, aby dotrzeć do replik, ale nie można trzymać ich bez końca. Duża liczba tombstone'ów zwiększa pracę podczas odczytów i compaction. Cassandra ma nawet progi ostrzegające i przerywające zapytania skanujące ogromne liczby tombstone'ów. Projektant balansuje więc bezpieczeństwo replikacji usunięć z kosztem przechowywania historii tego, czego już nie ma.
Grace period jest kontraktem z procesem naprawy
Parametr `gc_grace_seconds` nie powinien być traktowany wyłącznie jako liczba do optymalizacji miejsca. Określa czas, w którym niedostępne repliki muszą wrócić i zostać naprawione, zanim informacja o usunięciu może zniknąć. Zbyt agresywne skrócenie okresu bez odpowiednio częstego repair zwiększa ryzyko zombie. Konfiguracja bazy i procedury operacyjne są tu nierozłączne.
Tombstone jest także ciekawym przypadkiem informacji negatywnej w informatyce. Zapis „X istnieje” można przechowywać bezpośrednio. Informacja „X kiedyś istniało, ale już nie powinno wrócić” musi przetrwać wystarczająco długo, aby pokonać stare kopie w innych miejscach. Podobny problem pojawia się w cache'ach, replikowanych katalogach i synchronizacji plików. Usunięcie nie jest pustką; w rozproszonym świecie bywa pełnoprawnym zdarzeniem, które potrzebuje własnej wersji i retencji.
Właśnie dlatego operacje administracyjne mają wpływ na poprawność semantyczną bazy. Jeśli zespół wydłuży okres niedostępności węzła poza założony czas repair, zwykła decyzja operacyjna może zmienić to, czy stare dane da się bezpiecznie pogodzić z tombstone'ami. System rozproszony nie kończy się na kodzie serwera; procedury utrzymania, harmonogram napraw i parametry retencji są częścią algorytmu w praktyce.