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.
cassandra
maintenance
Mayur Patel
źródło
źródło
Odpowiedzi:
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 repair
jest zwykle zalecany cogc_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ą dlagc_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.
źródło
Według dokumentacji remontowej Cassandra ,
nodetool repair
powinny być prowadzone w następujących sytuacjach: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.
Poprawny. Przedstawiciel DataStax powiedział mi, że gdy uruchomisz
compact
rę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 uruchamianenodetool compact
i wdrożyć strategię tworzenia kopii zapasowych (migawki, przyrostowe kopie zapasowe lub obie).źródło
nodetool compact
jestem skazany na wieczność, chyba że zniszczę mój klaster? Czy istnieje sposób na automatyczne zagęszczanie, aby znów zacząć działać?upgradesstables
), może to zresetować na tyle, aby uchronić cię przed „piekłem ręcznego zagęszczania”.nodetool compact
. Ponadto możesz teraz użyć sstablesplit, aby pozbyć się tej nienaturalnie dużej sstable, abyś mógł „cofnąć”nodetool compact
.