Zadania konserwacji Apache Cassandra

W tej sekcji opisano okresowe zadania konserwacji dla systemu Cassandra.

Utrzymanie antyentropii

Węzły pierścieniowe Apache Cassandra wymagają okresowej konserwacji w celu zapewnienia spójności węzłów. Aby przeprowadzić tę konserwację, użyj tego polecenia:

apigee-service apigee-cassandra apigee_repair -pr

Apigee zaleca wykonanie tego polecenia podczas uruchamiania tego polecenia:

  • Uruchom w każdym węźle Cassandra (we wszystkich regionach i centrach danych).

  • Uruchamiaj na 1 węźle, aby zapewnić spójność we wszystkich węzłach w pierścieniu. Wykonywanie zadań naprawy na wielu węzłach jednocześnie może zaszkodzą Cassandra.

    Aby sprawdzić, czy zadanie naprawy w węźle zostało zakończone, sprawdź system.log plik do wpisu z identyfikatorem UUID ostatniej sesji naprawy i komunikatem „session complete successfully” (sesja ukończona). Oto przykładowy wpis logu:

    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
  • Uruchamiaj w okresach stosunkowo niewielkiego obciążenia (narzędzie nakłada znaczne obciążenie na ).
  • Uruchamiaj go co najmniej co siedem dni w celu wyeliminowania problemów związanych z „zapomniane usunięcia”.
  • Uruchamiaj go w różnych węzłach w różne dni lub zaplanuj tak, aby w przypadku kilka godzin między jego uruchomieniem w każdym węźle.
  • Użyj opcji -pr (zakres partycjonowania), aby określić podstawowy zakres partycjonowania tylko węzła.

Jeśli uwierzytelnianie JMX dla systemu Cassandra jest włączone, przy wywoływaniu funkcji nodetool musisz podać nazwę użytkownika i hasło. Na przykład:

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

Aby sprawdzić obsługiwane opcje w apigee_repair:, możesz też uruchomić to polecenie

apigee-service apigee-cassandra apigee_repair -h

Uwaga: apigee_repair to kod dotyczący naprawy narzędzia węzła Cassandry, który przeprowadza dodatkowe testy przed wykonaniem naprawy Cassandry.

Więcej informacji znajdziesz w tych materiałach:

.

Konserwacja pliku logu

Logi Cassandra są przechowywane w katalogu /opt/apigee/var/log/cassandra każdego węzła. Domyślnie można przesłać maksymalnie 50 plików dziennika o maksymalnym rozmiarze 20 MB utworzono; po osiągnięciu tego limitu starsze logi są usuwane po utworzeniu nowszych.

Jeśli zauważysz, że pliki dziennika Cassandra zajmują za dużo miejsca, możesz zmodyfikować plik cookie ilość miejsca przydzielonego na pliki dziennika przez edycję ustawień log4j.

  1. Edytuj /opt/apigee/customer/application/cassandra.properties na potrzeby skonfigurowania tych właściwości. 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ą następującego polecenia: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

Konserwacja miejsca na dysku

Należy regularnie sprawdzać wykorzystanie dysku Cassandra, aby mieć pewność, że co najmniej 50% każdy dysk jest bezpłatny. Jeśli wykorzystanie dysku wzrośnie powyżej 50%, zalecamy dodaj więcej miejsca na dysku, aby zmniejszyć odsetek wykorzystywany.

Cassandra automatycznie wykonuje te operacje, aby zmniejszyć wykorzystanie własnego dysku:

  • Usunięcie tokena uwierzytelniania po wygaśnięciu tokenów. Może jednak się zdarzyć, zwolnienie miejsca na dysku przez tokeny może potrwać kilka tygodni, konfiguracji. Jeśli automatyczne usuwanie nie jest wystarczające do utrzymania wystarczającą ilość miejsca na dysku, skontaktuj się z zespołem pomocy, aby dowiedzieć się więcej o ręcznym usuwaniu tokenów w celu przywrócenia kosmosu.

  • Uwaga na temat kompresowania danych: począwszy od Edge for Private Cloud w wersji 4.51.00, nowe instalacje Apigee Cassandra utworzy przestrzenie kluczy za pomocą Strategia kompresowania na każdym poziomie.

    Instalacje starszych wersji Edge for Private Cloud, które zostały uaktualnione do Private Cloud w wersji 4.51.00 zachowa poprzednią strategię kompresowania. Jeśli istniejący strategia kompresowania to SizeTieredCompactionStrategy, zalecamy zmianę na LeveledCompactionStrategy, która zapewnia lepsze wykorzystanie dysku.

Uwaga: gdy Cassandra przeprowadza kompresowanie danych, może to wymagać sporej liczby cykli procesora i pamięć. Jednak po zakończeniu kompresowania wykorzystanie zasobów powinno powrócić do normalnego poziomu. Polecenie 'Nodetool compactionstats' możesz uruchomić w każdym węźle aby sprawdzić, czy trwa kompresowanie. Dane wyjściowe funkcji compactionstats informują, czy oczekujące na wykonanie i szacowany czas zakończenia.