Cassandra: utrzymanie

Nie mam doświadczenia z Cassandrą, ale mam pewne doświadczenie z relacyjnymi bazami danych opartymi na SQL.

Nie udało mi się znaleźć informacji o najlepszych praktykach dotyczących sposobu utrzymania Cassandry po wdrożeniu. Czy konieczne jest VACUUM bazy danych? Powinienem pomyśleć, że ładowanie odczytu / zapisu powoduje fragmentację pamięci.

Lub bardziej ogólnie: jakie są najlepsze praktyki utrzymywania wdrożenia produkcyjnego Cassandra? Co należy robić w regularnych odstępach czasu, aby zachować sprawność systemu? Podręcznik operacyjny tak naprawdę nie omawia tego aspektu.

Dzięki.

Ogólnie rzecz biorąc, dobrze zaprojektowany klaster może żyć przez LATA bez dotykania. Mam klastry, które działały przez lata bezproblemowo. Oto jednak kilka wskazówek:

Monitorowanie jest niezwykle ważne:

1) Monitoruj opóźnienia. Użyj narzędzia opscenter lub swoich ulubionych narzędzi pomiarowych, aby śledzić opóźnienia. Zwiększające się opóźnienia mogą być oznakami nadchodzących problemów, w tym przerw GC (bardziej powszechnych w obciążeniach odczytu niż obciążeniach zapisu), niestabilnych problemów i tym podobnych.

2) Monitoruj liczbę sstable. Liczby SSTable wzrosną, jeśli przekroczysz zagęszczenie (każda sstable jest zapisywana dokładnie jeden raz - usuwanie jest obsługiwane przez łączenie starych sstables w nowe sstables poprzez kompaktowanie).

3) Monitoruj zmiany stanu węzłów (góra / dół itp.). Jeśli zauważysz trzepotanie węzłów, sprawdź, ponieważ nie jest to normalne.

4) Śledź zużycie dysku - tradycyjnie musisz pozostać poniżej 50% (szczególnie jeśli używasz kompresji STCS).

Jest kilka podstawowych rzeczy, które powinieneś i nie powinieneś robić regularnie:

1) Nie uruchamiaj jawnie nodetool compact. Wspominacie, że to zrobiliście, to nie jest fatalne, ale tworzy bardzo duże sstable, które wtedy mniej chętnie uczestniczą w zagęszczaniu posuwając się naprzód. Niekoniecznie musisz go uruchamiać, ale czasem może pomóc pozbyć się usuniętych / zastąpionych danych.

2) nodetool repairjest zwykle zalecany co gc_grace_seconds(domyślnie 10 dni). Są obciążenia, w których jest to mniej ważne - głównym powodem, dla którego POTRZEBUJESZ naprawy, jest upewnienie się, że znaczniki usuwania ( tombstones) są przesyłane przed ich wygaśnięciem (żyją dla gc_grace_seconds, jeśli węzeł jest wyłączony w momencie usunięcia, dane mogą wrócić do życia bez naprawy!). Jeśli nie wystawiasz usunięć i pytasz z wystarczającym poziomem spójności (na przykład odczytuje i zapisuje w QUORUM), możesz żyć bez naprawy.

3) Jeśli zamierzasz dokonać naprawy, rozważ zastosowanie naprawy przyrostowej i napraw małe zakresy naraz.

4) Strategie zagęszczania mają znaczenie - bardzo dużo. STCS jest świetny do zapisów, LCS jest świetny do odczytów. DTCS ma pewne dziwactwa.

5) Modele danych mają znaczenie - podobnie jak środowiska RDBMS / SQL mają kłopoty, gdy nieindeksowane zapytania trafiają do dużych tabel, Cassandra może powodować problemy z bardzo dużymi wierszami / partycjami.

6) Migawki są tanie. Bardzo tani. Niemal natychmiastowe, tylko twarde łącza, natychmiast nie kosztują prawie żadnego miejsca na dysku. Użyj migawki przed aktualizacją wersji, zwłaszcza wersji głównych.

7) Uważaj na usuwanie. Jak wskazano w punkcie 2, delete tworzy więcej danych na dysku i nie zwalnia ich dla AT LEAST gc_grace_seconds.

Gdy wszystko inne zawiedzie:

Widziałem artykuły, które sugerują, że Cassandra w prod wymaga dedykowanego szefa do zarządzania klastrem dowolnej wielkości - nie wiem, czy to koniecznie prawda, ale jeśli martwisz się, możesz zatrudnić zewnętrznego konsultanta (TheLastPickle, Pythian ) lub zawrzeć umowę o wsparcie (Datastax), aby zapewnić ci spokój.

Według dokumentacji remontowej Cassandra , nodetool repairpowinny być prowadzone w następujących sytuacjach:

• Najlepszą praktyką jest zaplanowanie napraw co tydzień. Uwaga: jeśli usunięcia nigdy nie wystąpią, nadal należy planować regularne naprawy. Pamiętaj, że ustawienie wartości null dla kolumny to usunięcie.
• Podczas odzyskiwania węzła. Na przykład przy przywracaniu węzła do klastra po awarii.
• W węzłach zawierających dane, które nie są często odczytywane.
• Aby zaktualizować dane w wyłączonym węźle.

Powinienem pomyśleć, że ładowanie odczytu / zapisu powoduje fragmentację pamięci.

Dane w Cassandrze nie „fragmentują” w sposób, w jaki myślisz. Usunięcia powodują jednak umieszczenie nagrobków, a normalny kompaktowy proces eliminuje nagrobki.

Rozumiem teraz, że zagęszczanie to wielka sprawa i działa automatycznie

Poprawny. Przedstawiciel DataStax powiedział mi, że gdy uruchomisz compactręcznie, zawsze będziesz musiał uruchomić go ręcznie. Powodem jest to, że zagęszczanie polega na „kompaktowaniu” wszystkich istniejących SSTABLES w przestrzeni klucza w jeden plik SSTABLE. Możliwe, że niektóre rodziny kolumn w tym pliku SSTABLE są małe, a zwiększenie ich wartości powyżej progu zagęszczenia zajmie tak długo, że prawdopodobieństwo ponownego uruchomienia automatycznego zagęszczania jest bardzo niskie.

Zasadniczo należy zaplanować regularne nodetool repair, nigdy nie uruchamiane nodetool compacti wdrożyć strategię tworzenia kopii zapasowych (migawki, przyrostowe kopie zapasowe lub obie).