Zarządzanie kronikowaniem w MongoDB

MongoDB, podobnie jak każda inna baza danych, może zawieść podczas wykonywania operacji zapisu. W takim przypadku potrzebujemy strategii, która zatrzyma operację gdzieś, aby baza danych mogła zostać wznowiona po przywróceniu jej do działania.

W MongoDB używamy księgowania, w ramach którego istnieje zapis z wyprzedzeniem w logowaniu do plików dziennika na dysku, aby zachować dane dostępne w przypadku awarii. Silnik przechowywania WiredTiger może używać punktów kontrolnych, aby zapewnić spójny widok danych na dysku i umożliwić MongoDB odzyskanie danych z ostatniego punktu kontrolnego, ale tylko wtedy, gdy nie został on niespodziewanie zamknięty. W przeciwnym razie dla informacji, które wystąpiły podczas ostatniego punktu kontrolnego, w celu odzyskania takich danych musi być włączone kronikowanie.

Procedura procesu odzyskiwania jest następująca:baza danych przeszuka pliki danych w celu znalezienia identyfikatora ostatniego punktu kontrolnego, użyj tego identyfikatora do wyszukania w plikach dziennika rekordu, który do niego pasuje i następnie zastosuj operacje w plikach dziennika od ostatniego punktu kontrolnego.

Jak działa księgowanie w WiredTiger Storage Engine

Dla każdego klienta, który inicjuje operację zapisu, WiredTiger tworzy rekord dziennika składający się z wewnętrznych operacji zapisu wyzwolonych przez początkowy zapis. Rozważmy dokument w kolekcji, który ma zostać zaktualizowany i spodziewamy się, że jego indeks również zostanie zmodyfikowany. WiredTiger utworzy pojedynczy rekord dziennika, który będzie zawierał operację aktualizacji i odpowiednie modyfikacje indeksu.

Ten rekord będzie przechowywany w buforze w pamięci, którego maksymalna pojemność wynosi 128 kB. Silnik pamięci masowej synchronizuje następnie buforowane rekordy dziennika z dyskiem, gdy zostanie spełniony jeden z następujących warunków:

Operacja zapisu zawiera/implikuje problem z zapisem j:true.
WiredTiger tworzy nowy plik dziennika, który jest po każdych 100 MB danych.
Po każdych 100 milisekundach, w zależności od storage.journal.commitIntervalMs.
W przypadku członków zestawu replik:
- Instancja operacji oczekujących na wpisy oploga, tj. operacji odczytu wykonanych w ramach przyczynowo zgodnych sesji i zapytań skanowania do przodu względem oploga.
- Po każdym wsadowym zastosowaniu wpisów oplog w przypadku członków drugorzędnych.

W przypadku twardego wyłączenia mongod, jeśli trwają operacje zapisu, aktualizacje mogą zostać utracone, nawet jeśli rekordy dziennika pozostaną w buforach WiredTiger.

Kompresja danych dziennika

Domyślne ustawienie w MongoDB powoduje, że WiredTiger używa szybkiej kompresji danych dziennika. Można to zmienić w zależności od wybranego algorytmu kompresji przy użyciu ustawienia storage.wiredTiger.engineConfig.journalCompressor. Te rekordy dziennika są kompresowane tylko wtedy, gdy ich rozmiar jest większy niż 128 bajtów, co jest minimalnym rozmiarem rekordu dziennika WiredTiger.

Ograniczanie rozmiaru pliku dziennika

Maksymalny rozmiar pliku dziennika wynosi 100 MB, dlatego jeśli plik przekroczy ten limit, zostanie utworzony nowy.

Gdy plik dziennika został użyty do odzyskiwania lub gdy są pliki starsze niż ten, którego można użyć do odzyskania z ostatniego punktu kontrolnego, WiredTiger automatycznie je usuwa.

Wstępna alokacja

Pliki dziennika mogą być wstępnie przydzielane za pomocą mechanizmu pamięci masowej WiredTiger, jeśli proces mongod ustali, że bardziej wydajne jest wstępne przydzielanie plików dziennika niż tworzenie nowych.

Jak działa rejestrowanie w aparacie pamięci masowej

Silnik pamięci masowej w pamięci został określony jako część ogólnej dostępności (GA), począwszy od MongoDB Enterprise w wersji 3.2.6. Dzięki temu mechanizmowi przechowywania dane są przechowywane w pamięci, dlatego nie ma oddzielnej techniki kronikowania. Jeśli istnieją jakieś operacje zapisu dotyczące zapisu (j:true), zostaną one natychmiast potwierdzone.

W przypadku zestawu replik z głosującym członkiem korzystającym z mechanizmu pamięci masowej w pamięci należy ustawić writeConcernMajorityJournalDefault na false. W przeciwnym razie, jeśli jest to ustawione na true, zestaw replik zarejestruje ostrzeżenie o uruchomieniu.

Gdy ta opcja jest ustawiona na false, baza danych nie będzie czekać na w:„większość” zapisów w dzienniku na dysku przed potwierdzeniem zapisów. Wadą tego podejścia jest to, że w przypadku większości operacji zapisu można cofnąć się w przypadku przejściowej utraty (takiej jak ponowne uruchomienie lub awaria) większości węzłów w danym zestawie replik.

Jeśli używasz silnika przechowywania MMapv1, wstępne przydzielanie dziennika można wyłączyć za pomocą opcji --nopreallocation podczas uruchamiania mongod.

W przypadku silnika przechowywania WiredTiger, począwszy od MongoDB w wersji 4.0 w górę, nie jest możliwe określenie opcji --nojournal ani nawet opcji storage.journal.enabled:false dla elementów zestawu replik korzystających z aparatu przechowywania WiredTiger.

Zarządzanie dziennikowaniem

Wyłączanie dziennika

Dziennikowanie można wyłączyć tylko w przypadku wdrożeń autonomicznych i nie jest to zalecane w przypadku systemów produkcyjnych. W przypadku MongoDB w wersji 4.0 i nowszych nie można określić ani opcji --nojournal ani storage.journal.enabled:false, gdy zaangażowane są elementy zestawu replik korzystające z mechanizmu przechowywania WiredTiger.

Aby wyłączyć księgowanie, uruchom mongod z opcją wiersza poleceń --nojournal.

Monitoruj stan czasopisma

Aby uzyskać statystyki dotyczące dziennika, użyj polecenia db.serverStatus(), które zwraca wiredTiger.log.

Pobierz potwierdzenie zatwierdzenia

Używamy kwestii zapisu z opcją j, aby uzyskać potwierdzenie zatwierdzenia. {j:prawda}. W takim przypadku należy włączyć kronikowanie, w przeciwnym razie instancja mongod może spowodować błąd.

Jeśli włączone jest księgowanie, w:„większość” może to oznaczać j:prawda.

W przypadku zestawu replik, gdy j:true, konfiguracja wymaga tylko podstawowego zapisu do dziennika, niezależnie od problemu w: write.

Jednak nawet jeśli j:true jest skonfigurowane dla zestawu replik, mogą wystąpić wycofania z powodu przełączenia awaryjnego podstawowego zestawu replik.

Nieoczekiwane odzyskiwanie danych po wyłączeniu

Wszystkie pliki dziennika w katalogu dziennika są odtwarzane po każdym ponownym uruchomieniu MongoDB po awarii przed wykryciem serwera. Ponieważ ta operacja zostanie zapisana w danych wyjściowych dziennika, nie będzie potrzeby uruchamiania --repair.

Zmiana kompresora dziennika WiredTiger

Snappy Compressor to domyślny algorytm kompresji dziennika. Można to jednak zmienić w zależności od konfiguracji instancji mongod.

Dla samodzielnej instancji mongod:

Ustaw parametr storage.wiredTiger.engineConfig.journalCompressor na nową wartość, aby go zaktualizować. Najodpowiedniejszym sposobem, aby to zrobić, jest użycie pliku konfiguracyjnego, ale jeśli używasz opcji wiersza poleceń, musisz zaktualizować opcję wiersza polecenia --wiredTigerJournalCompressor podczas ponownego uruchamiania.
Zamknij instancję mongod, łącząc się z powłoką mongo instancji i wydaj polecenie:db.shutdownServer() lub db.getSiblingDB('admin ).shutdownServer()
Ponownie uruchom instancję mongod:
1. Jeśli używasz pliku konfiguracyjnego, użyj:mongod -f <ścieżka do pliku.conf>
2. Jeśli używasz opcji wiersza poleceń, zaktualizuj wiredTigerJournalCompressor:
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

Dla członka zestawu replik:

Zamknij instancję mongod:db.shutdownServer() lub db.getSiblingDB(‘admin).shutdownServer()
Wprowadź następujące zmiany w pliku konfiguracyjnym:
1. Ustaw storage.journal.enabled na false.
2. Skomentuj ustawienia replikacji
3. Ustaw parametr disableLogicalSessionCacheRefresh na true.

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

Ponownie uruchom instancję mongod:
1. Jeśli używasz pliku konfiguracyjnego, użyj:mongod -f <ścieżka do pliku.conf>
2. Jeśli używasz opcji wiersza polecenia:dołącz opcję --nojournal, usuń wszystkie opcje wiersza polecenia replikacji tj. --replUstaw i ustaw parametr disableLogicalSessionCacheRefresh na wartość true
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

Zamknij instancję mongod:

db.shutdownServer() or db.getSiblingDB(‘admin).shutdownServer()

Zaktualizuj plik konfiguracyjny, aby przygotować się do ponownego uruchomienia elementu zestawu replik z nowym kompresorem dziennika:Usuń pamięć masową. journal.enabled, odkomentuj ustawienia replikacji dla wdrożenia, usuń opcję disableLogicalSessionCacheRefresh i na koniec usuń storage.wiredTiger.engineConfig.journalCompressor.

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

Ponownie uruchom instancję mongod jako element zestawu replik

Jeśli używasz pliku konfiguracyjnego, użyj:mongod -f <ścieżka do pliku.conf>
Jeśli używasz opcji wiersza poleceń:usuń opcje --nojournal i --wiredTigerJournalCompressor. Uwzględnij opcje wiersza polecenia replikacji i usuń parametr disableLogicalSessionCacheRefresh.

mongod --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...

Wniosek

Aby usługa MongoDB gwarantowała trwałość operacji zapisu, używane jest rejestrowanie, dzięki któremu dane są zapisywane na dysku z wyprzedzeniem Logowanie. O ile silnik pamięci masowej WiredTiger (co jest najbardziej preferowany) może odzyskać dane przez ostatnie punkty kontrolne, jeśli MongoDB nieoczekiwanie zakończy działanie, a rejestrowanie nie zostanie włączone, odzyskanie takich danych stanie się niemożliwe. W przeciwnym razie, jeśli włączone jest rejestrowanie, MongoDB może ponownie zastosować operacje zapisu po ponownym uruchomieniu i zachować spójny stan.