Zadania konserwacji Apache Cassandra

W tej sekcji opisano okresowe zadania konserwacyjne dotyczące Cassandra.

Konserwacja antyentropii

Węzły pierścienia Apache Cassandra wymagają okresowej konserwacji, aby zapewnić spójność wszystkich węzłów. Aby przeprowadzić tę konserwację, użyj tego polecenia:

apigee-service apigee-cassandra apigee_repair -pr

Apigee zaleca wykonanie tych czynności podczas uruchamiania tego polecenia:

  • Uruchamianie na każdym węźle Cassandra (we wszystkich regionach lub centrach danych).
  • działać na jednym węźle naraz, aby zapewnić spójność we wszystkich węzłach w pierścieniu; Uruchamianie zadań naprawczych na wielu węzłach jednocześnie może pogorszyć stan usługi Cassandra.

    Aby sprawdzić, czy zadanie naprawy na węźle zostało ukończone, sprawdź w pliku system.log węzła, czy zawiera on wpis z identyfikatorem UUID ostatniej sesji naprawy i frazą „sesja została zakończona”. Oto przykładowy wpis w dzienniku:

    INFO [AntiEntropySessions:1] 2015-03-01 10:02:56,245 RepairSession.java (line 282) [repair #2e7009b0-c03d-11e4-9012-99a64119c9d8] session completed successfully"
    Ref: https://support.datastax.com/hc/en-us/articles/204226329-How-to-check-if-a-scheduled-nodetool-repair-ran-successfully
  • uruchamiać w okresach stosunkowo niskiego obciążenia (narzędzie powoduje znaczne obciążenie systemu);
  • Uruchom co najmniej co 7 dni, aby wyeliminować problemy związane z „zapomnianymi” operacjami usuwania w Cassandra.
  • Uruchom go na różnych węzłach w różne dni lub zaplanuj go tak, aby pomiędzy uruchomieniem na poszczególnych węzłach było kilka godzin przerwy.
  • Użyj opcji -pr (zakres partycjonowania) do określenia zakresu partycjonowania głównego tylko dla węzła.

Jeśli usługa Cassandra ma włączone uwierzytelnianie JMX, podczas wywoływania nodetool musisz podać nazwę użytkownika i hasło. Na przykład:

apigee-service apigee-cassandra apigee_repair -u username -pw password -pr

Możesz też uruchomić to polecenie, aby sprawdzić obsługiwane opcje apigee_repair:

apigee-service apigee-cassandra apigee_repair -h

Uwaga: apigee_repair to folia wokół naprawy nodetool w Cassandra, która przeprowadza dodatkowe kontrole przed wykonaniem naprawy w Cassandra.

Więcej informacji znajdziesz w tych materiałach:

Konserwacja plików dziennika

Logi Cassandra są przechowywane w katalogu /opt/apigee/var/log/apigee-cassandra w każdym węźle. Domyślnie można utworzyć maksymalnie 50 plików dziennika o rozmiarze do 20 MB. Gdy zostanie osiągnięty ten limit, starsze dzienniki są usuwane podczas tworzenia nowych.

Jeśli okaże się, że pliki dziennika Cassandra zajmują zbyt dużo miejsca, możesz zmienić ilość miejsca przydzielonego do plików dziennika, edytując ustawienia log4j.

  1. Aby ustawić te właściwości, kliknij Edytuj /opt/apigee/customer/application/cassandra.properties. Jeśli plik nie istnieje, utwórz go:
    conf_logback_maxfilesize=20MB
    # max file size
    conf_logback_maxbackupindex=50 # max open files
  2. Uruchom ponownie Cassandra za pomocą tego polecenia:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

Konserwacja miejsca na dysku

Należy regularnie sprawdzać wykorzystanie dysków Cassandra, aby mieć pewność, że na każdym z nich jest co najmniej 50% wolnego miejsca. Jeśli wykorzystanie dysku wzrośnie powyżej 50%, zalecamy dodanie więcej miejsca na dysku, aby zmniejszyć procent wykorzystania.

Aby zmniejszyć wykorzystanie dysku, Cassandra automatycznie wykonuje te operacje:

  • usuwanie tokenów uwierzytelniania po wygaśnięciu. W zależności od konfiguracji może jednak minąć kilka tygodni, zanim zwolnione zostanie miejsce na dysku zajmowane przez tokeny. Jeśli automatyczne usuwanie nie wystarcza do utrzymania wystarczającej ilości miejsca na dysku, skontaktuj się z zespołem pomocy, aby dowiedzieć się, jak ręcznie usunąć tokeny, aby odzyskać miejsce.
  • Uwaga dotycząca kompresji danych: od wersji Edge for Private Cloud 4.51.00 nowe instalacje Apigee Cassandra będą tworzyć przestrzenie kluczy za pomocą strategii kompresji poziomej.

    Instalacje starszych wersji Edge for Private Cloud, które zostały zaktualizowane do wersji Private Cloud 4.51.00, będą nadal korzystać z poprzedniej strategii kompresji. Jeśli dotychczasowa strategia kompresji to SizeTieredCompactionStrategy, zalecamy zmianę na LeveledCompactionStrategy, która zapewnia lepsze wykorzystanie dysku.

Uwaga: gdy Cassandra wykonuje kompresję danych, może to zająć znaczną ilość cykli procesora i pamięci. Po zakończeniu kompresji wykorzystanie zasobów powinno wrócić do normalnego poziomu. Aby sprawdzić, czy kompresja jest uruchomiona, możesz uruchomić polecenie 'Nodetool compactionstats' na każdym węźle. Dane wyjściowe polecenia compactionstats informują, czy są oczekujące kompresje do wykonania, oraz podają szacowany czas ich ukończenia.