doświadczenia z nagrobkami w Apache Cassandra

wykrywanie i zapobieganie nagrobkom

nagrobki można wykryć w dziennikach i monitorując określone wskaźniki. Ich żywotność jest określona przez ustawienie tabeli gc_grace_seconds.

dostrajanie ustawień tabeli

• gc_grace_seconds

domyślnym ustawieniem dla gc_grace_seconds jest 864000 (10 dni). Dla nas sensowne było obniżenie tej wartości do 345600 (4 dni). Jeśli zdecydujesz się zmienić okres karencji, upewnij się, że wykonujesz naprawy w tym przedziale czasowym.

możesz po prostu zmienić wartość istniejących tabel lub utworzyć nową tabelę w ten sposób:

Utwórz przestrzeń klawiszy tabeli.tablename WITH GC_GRACE_SECONDS = 345600;

ALTER TABLE keyspace.tablename WITH GC_GRACE_SECONDS = 345600;

• TTL

po przekroczeniu przez TTL określonego zakresu czasu wiersze są usuwane, a wartości zamieniane na nagrobki. Domyślnie wiersze / wartości nie wygasają.

doświadczając problemów z nagrobkami stwierdziliśmy, że musimy wydłużyć czas życia naszych stołów. Mając tę wartość ustawioną na 1 ½ dnia, niepowodzenie zadań zapisu skutkowało usunięciem wszystkich danych z tabeli jednocześnie. Ze względu na brakujące aktualizacje, każdy rząd był oznaczony nagrobkiem. Ustawienie wyższej wartości pozwala nam na ponowne uruchomienie prac w czasie i uniknięcie niepotrzebnego tworzenia dużej ilości nagrobków.

• tombstone_warn_threshold

Ostrzeżenie progu nagrobka jest domyślnie ustawione na 1.000 i będzie widoczne w logach w przypadku skanowania więcej niż 1.000 nagrobków za pomocą jednego zapytania.

• tombstone_failure_threshold

próg uszkodzenia nagrobka jest osiągany, gdy skanuje się 100 000 nagrobków za pomocą jednego zapytania. W takim przypadku zapytanie zostanie przerwane, co oznacza, że dane z dotkniętej tabeli nie mogą być już odpytywane.

te ustawienia progowe można zmienić, ale należy pamiętać, że zwiększenie ich może prowadzić do wyczerpania pamięci węzłów.

Wykonuj regularne naprawy

Cassandra ma wysoką odporność na awarie i działa dobrze, nawet jeśli węzeł jest chwilowo niedostępny. Niemniej jednak, najlepszą praktyką jest uruchamianie nodetool repair po awarii węzła. Zwłaszcza jeśli chcesz uniknąć utraty danych za wszelką cenę.

podczas procesu naprawy węzeł, który był niedostępny, otrzyma zapisy, które miały miejsce podczas jego przestoju.

jest to dobre podejście do uruchamiania napraw w ciągu gc_grace_seconds i regularnie, w przeciwnym razie możesz doświadczyć przypadków, w których usunięte dane zostaną przywrócone.

istnieje kilka sposobów automatycznego uruchamiania napraw. Jedną z nich jest Cassandra Reaper. To narzędzie jest dostarczane z ładnym interfejsem użytkownika, który ułatwia planowanie napraw.

Skonfiguruj i uruchom zagęszczanie

aby ostatecznie usunąć nagrobki i zwolnić miejsce na dysku, należy uruchomić zagęszczanie. Istnieją różne rodzaje zagęszczania. The minor compaction wykonuje compaction nad wszystkimi sstables i uruchamia się automatycznie w Cassandra. Usuwa wszystkie nagrobki, które są starsze niż okres łaski. Jeśli ręcznie uruchomisz zagęszczanie na wszystkich sstables, nazywa się to zagęszczaniem głównym. Należy pamiętać, że zagęszczanie musi zostać uruchomione dla każdego węzła z osobna. Masz również możliwość uruchomienia zagęszczania zdefiniowanego przez użytkownika tylko na grupie określonych sstables.

zagęszczanie danych w C* zwykle oznacza scalanie sstables w jeden nowy sstable. Podczas wykonywania odczytów w wielu wierszach, im więcej sstables musi zostać zeskanowanych, tym proces staje się wolniejszy. Aby temu zapobiec, zagęszczanie musi odbywać się regularnie.

aby rozpocząć kompakty ręcznie, możesz użyć nodetool compact. W przypadku, gdy nie określisz przestrzeni kluczowej lub tabeli, zagęszczenie zostanie uruchomione na wszystkich obszarach kluczowych i tabelach.

nodetool compact keyspace tablename

to polecenie rozpoczyna zagęszczanie podanej tabeli. Powinieneś dowiedzieć się, która strategia zagęszczania jest skonfigurowana dla Twoich tabel i porównać ją z alternatywnymi strategiami. Jeśli chcesz dowiedzieć się, czy inna strategia lepiej spełnia Twoje potrzeby, możesz zapoznać się z dokumentacją DataStax.

Monitor table metrics

1. Nodetool

Nodetool jest interfejsem linii poleceń Cassandry. Jest to przydatne, jeśli chcesz dowiedzieć się więcej o wydajności klastrów. Możesz sprawdzić całą listę możliwych poleceń dostarczanych przez DataStax.

polecenia Nodetool muszą być wykonywane dla każdego węzła z osobna. Uruchamiamy C* na Kubernetes, więc możemy otworzyć powłokę dla działającego Cassandra pod w następujący sposób:

kubectl exec-it cassandra-0-N poleca bash

od tego momentu możemy użyć nodetool aby uzyskać różne informacje o naszych tabelach. Polecenie nodetool tablestats może być wykonane do drukowania statystyk dla poszczególnych obszarów klawiszy lub tabel:

wartości dla “Average tombstones per slice” i “Maximum tombstones per slice” mówią, ile nagrobków zostało zeskanowanych na zapytanie w ciągu ostatnich pięciu minut. Jeśli wartość ta jest bardzo wysoka, może być konieczne częstsze uruchamianie zagęszczania dla tej tabeli.

2. SSTable Tools

przed wykonaniem Sstable Tools Cassandra musi zostać zatrzymana. Polecenie sstableutil wyświetli listę plików sstable istniejących dla określonej tabeli. Wykonanie sstablemetadata na tych plikach dostarczy użytecznych informacji o podanej tabeli, takich jak na przykład TTL i oszacowanie spadających nagrobków.

3. Prometheus i Grafana

nasz monitoring C * jest skonfigurowany z Prometheus i Grafana. Po otrzymaniu ostrzeżeń o progach nagrobków postanowiliśmy dodać panel do naszego pulpitu nawigacyjnego, który daje nam wyobrażenie o zachowaniu nagrobków dla każdego z naszych stołów.

Kasandra ma tabelę o nazwie “TombstoneScannedHistogram”, która przedstawia histogram nagrobków, które zostały zeskanowane na zapytanie. Pokazując 99. percentyl zobaczymy, czy coś jest nie tak.