Správa žurnálování v MongoDB

MongoDB stejně jako jakákoli jiná databáze může selhat při provádění operace zápisu. V takovém případě potřebujeme strategii, která někde udrží operaci, aby se databáze mohla obnovit, když bude obnovena zpět do provozu.

V MongoDB používáme žurnálování, při kterém dochází k předběžnému zápisu do souborů žurnálu na disku, aby byla data k dispozici v případě selhání. Úložný modul WiredTiger může používat kontrolní body k poskytování konzistentního pohledu na data na disku a umožňuje MongoDB obnovit se z posledního kontrolního bodu, ale pouze v případě, že se neočekávaně neukončí. Jinak pro informace, které se vyskytly během posledního kontrolního bodu, musí být povoleno žurnálování, aby se taková data obnovila.

Postup procesu obnovy je takový, že:databáze se podívá do datových souborů, aby nalezla identifikátor posledního kontrolního bodu, pomocí tohoto identifikátoru vyhledá v souborech deníku záznam, který mu odpovídá a poté použijte operace v souborech žurnálu od posledního kontrolního bodu.

Jak funguje žurnálování ve WiredTiger Storage Engine

Pro každého klienta, který zahájí operaci zápisu, vytvoří WiredTiger záznam žurnálu, který se skládá z interních operací zápisu, které byly spuštěny počátečním zápisem. Zvažte dokument v kolekci, který má být aktualizován, a očekáváme, že bude upraven i jeho index. WiredTiger vytvoří jeden záznam žurnálu, který bude zahrnovat operaci aktualizace a odpovídající úpravy indexu.

Tento záznam bude uložen ve vyrovnávací paměti, jejíž maximální kapacita je 128 kB. Úložné jádro pak synchronizuje tyto záznamy žurnálu uložené ve vyrovnávací paměti na disk, když je splněna některá z následujících podmínek:

Operace zápisu zahrnuje/implikuje obavu o zápis j:true.
WiredTiger vytvoří nový soubor deníku, který je po každých 100 MB dat.
Po každých 100 milisekundách v závislosti na storage.journal.commitIntervalMs.
V případě členů sady replik:
- Instance operací čekajících na záznamy oplogu, tj. operace čtení prováděné jako součást kauzálně konzistentních relací a dopředné skenování dotazů proti oplogu.
- Po každé dávkové aplikaci položek oplogu v případě sekundárních členů.

V případě tvrdého vypnutí mongodu, pokud probíhaly operace zápisu, může dojít ke ztrátě aktualizací, i když záznamy žurnálu zůstanou ve vyrovnávací paměti WiredTiger.

Komprese deníkových dat

Výchozí nastavení v MongoDB nařizuje WiredTiger používat rychlou kompresi pro data žurnálu. Toto lze změnit v závislosti na tom, který kompresní algoritmus chcete, pomocí nastavení storage.wiredTiger.engineConfig.journalCompressor. Tyto záznamy protokolu jsou komprimovány pouze tehdy, pokud je jejich velikost větší než 128 bajtů, což je minimální velikost záznamu protokolu WiredTiger.

Omezení velikosti souboru deníku

Maximální velikost souboru deníku je 100 MB, a proto pokud soubor překročí tento limit, bude vytvořen nový.

Poté, co byl soubor deníku použit při obnově nebo spíše existují soubory starší než ten, který lze použít k obnově z posledního kontrolního bodu, WiredTiger je automaticky odstraní.

Předběžné přidělení

Soubory deníků mohou být předem alokovány pomocí úložiště WiredTiger, pokud proces mongod určí, že je efektivnější předem alokovat soubory deníku než vytvářet nové.

Jak funguje žurnálování v In-Memory Storage Engine

In-memory storage Engine byl uveden jako součást obecné dostupnosti (GA) počínaje MongoDB Enterprise verze 3.2.6. S tímto úložištěm jsou data uchovávána v paměti, takže neexistuje žádná samostatná technika žurnálování. Pokud existují nějaké operace zápisu s problémem zápisu (j:true), budou okamžitě potvrzeny.

U sady replik s hlasujícím členem využívajícím modul úložiště v paměti je třeba nastavit writeConcernMajorityJournalDefault na hodnotu false. V opačném případě, pokud je toto nastaveno na hodnotu true, sada replik zaznamená varování při spuštění.

Pokud je tato volba nastavena na hodnotu false, databáze nebude čekat na zápis w:„většina“ zápisu do deníku na disku, než zápis potvrdí. Nevýhodou tohoto přístupu je, že u většiny operací zápisu se mohou vrátit zpět v případě přechodné ztráty (jako je restart nebo pád) většiny uzlů v dané sadě replik.

Pokud používáte úložný stroj MMapv1, lze předběžné přidělení žurnálu deaktivovat pomocí volby --nopreallocation při spouštění mongoda.

U úložiště WiredTiger od verze MongoDB 4.0 výše není možné určit volbu --nojournal nebo dokonce storage.journal.enabled:false pro členy sady replik používající úložiště WiredTiger.

Správa ukládání do deníku

Deaktivace ukládání do deníku

Ukládání deníků lze zakázat pouze pro samostatná nasazení a nedoporučuje se pro produkční systémy. Pro MongoDB verze 4.0 a vyšší nelze specifikovat ani volbu --nojournal, ani storage.journal.enabled:false, pokud jsou zahrnuti členové sady replik, kteří používají úložiště WiredTiger.

Chcete-li zakázat žurnálování, spusťte mongod s volbou příkazového řádku --nojournal.

Sledování stavu deníku

K získání statistiky žurnálu použijte příkaz db.serverStatus(), který vrací wiredTiger.log.

Získejte potvrzení o závazku

Používáme možnost zápisu obavy s j k získání potvrzení potvrzení. {j:pravda}. V tomto případě musí být povoleno žurnálování, jinak může instance mongoda způsobit chybu.

Pokud je povoleno žurnálování, w:“většina” to může znamenat j:true.

Pokud je u sady replik j:true, nastavení vyžaduje, aby zápis do deníku zapisoval pouze primární zdroj, bez ohledu na problém zápisu w:.

Avšak i když je j:true nakonfigurováno pro sadu replik, může dojít k vrácení zpět kvůli primárnímu převzetí služeb při selhání sady replik.

Obnova dat při neočekávaném vypnutí

Všechny soubory žurnálu v adresáři žurnálu se přehrají vždy, když se MongoDB restartuje po havárii předtím, než je detekován server. Protože tato operace bude zaznamenána ve výstupu protokolu, nebude nutné spouštět --repair.

Změna WiredTiger Journal Compressor

Snappy kompresor je výchozí algoritmus komprese žurnálu. To však lze změnit v závislosti na nastavení instance mongoda.

Pro samostatnou instanci mongoda:

Chcete-li jej aktualizovat, nastavte storage.wiredTiger.engineConfig.journalCompressor na novou hodnotu. Nejvhodnější způsob, jak toho dosáhnout, je prostřednictvím konfiguračního souboru, ale pokud používáte možnosti příkazového řádku, musíte během restartu aktualizovat možnost příkazového řádku --wiredTigerJournalCompressor.
Vypněte instanci mongoda připojením k mongo shellu instance a zadejte příkaz:db.shutdownServer() nebo db.getSiblingDB('admin ).shutdownServer()
Restartujte instanci mongoda:
1. Pokud používáte konfigurační soubor, použijte:mongod -f
2. Pokud používáte možnosti příkazového řádku, aktualizujte wiredTigerJournalCompressor:
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

Pro člena sady replik:

Vypněte instanci mongoda:db.shutdownServer() nebo db.getSiblingDB(‘admin).shutdownServer()
Proveďte v konfiguračním souboru následující změny:
1. Nastavte storage.journal.enabled na hodnotu false.
2. Komentujte nastavení replikace
3. Nastavte parametr disableLogicalSessionCacheRefresh na hodnotu true.

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

Restartujte instanci mongoda:
1. Pokud používáte konfigurační soubor, použijte:mongod -f
2. Pokud používáte možnosti příkazového řádku:zahrňte možnost --nojournal, odeberte všechny možnosti příkazového řádku replikace tj. --replSet a nastavte parametr disableLogicalSessionCacheRefresh na hodnotu true
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

Vypnutí instance mongoda:

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

Aktualizujte konfigurační soubor, abyste se připravili na restartování člena sady replik s novým žurnálovým kompresorem:Odeberte úložiště. journal.enabled, odkomentujte nastavení replikace pro nasazení, odeberte možnost disableLogicalSessionCacheRefresh a nakonec odstraňte storage.wiredTiger.engineConfig.journalCompressor.

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

Restartujte instanci mongoda jako člena sady replik

Pokud používáte konfigurační soubor, použijte:mongod -f
Pokud používáte možnosti příkazového řádku:odstraňte možnosti --nojournal a --wiredTigerJournalCompressor. Zahrňte možnosti příkazového řádku replikace a odeberte parametr disableLogicalSessionCacheRefresh.

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

Závěr

Aby MongoDB zaručila trvanlivost operace zápisu, používá se žurnálování, kdy se data zapisují na disk předem protokolování. Úložný modul WiredTiger (který je nejpreferovanější) dokáže obnovit data přes poslední kontrolní body, ale pokud se MongoDB neočekávaně ukončí a žurnálování nebylo povoleno, obnova takových dat nebude možná. V opačném případě, pokud je povoleno žurnálování, MongoDB může znovu použít operace zápisu při restartu a udržovat konzistentní stav.