Journaling beheren in MongoDB

MongoDB kan net als elke andere database mislukken bij het uitvoeren van een schrijfbewerking. In dat geval hebben we een strategie nodig die de bewerking ergens houdt, zodat de database kan worden hervat wanneer deze weer in bedrijf is.

In MongoDB gebruiken we journaling waarbij er een write-ahead logging is naar on-disk journaalbestanden om de data beschikbaar te houden in geval van storing. De WiredTiger-opslagengine kan controlepunten gebruiken om een consistent beeld van gegevens op schijf te bieden en MongoDB in staat te stellen te herstellen van het laatste controlepunt, maar alleen als het niet onverwachts werd afgesloten. Anders moet voor de informatie die tijdens het laatste controlepunt is opgetreden, journaal zijn ingeschakeld om dergelijke gegevens te herstellen.

De procedure voor het herstelproces is dat:de database in de gegevensbestanden kijkt om de identifier van het laatste checkpoint te vinden, deze identifier gebruikt om in de journaalbestanden te zoeken naar het record dat ermee overeenkomt en pas vervolgens de bewerkingen toe in de journaalbestanden sinds het laatste controlepunt.

Hoe logboekregistratie werkt in de WiredTiger Storage Engine

Voor elke client die een schrijfbewerking start, maakt de WiredTiger een journaalrecord dat is samengesteld uit interne schrijfbewerkingen die zijn geactiveerd door de eerste schrijfbewerking. Denk aan een document in een collectie dat moet worden bijgewerkt en we verwachten dat de index ervan ook wordt gewijzigd. De WiredTiger zal een enkel journaalrecord creëren waarin de update-bewerking en de bijbehorende indexaanpassingen zijn verwerkt.

Dit record wordt opgeslagen in een in-memory buffer met een maximale capaciteit van 128kB. De opslagengine synchroniseert vervolgens deze gebufferde journaalrecords naar schijf wanneer aan een van de volgende voorwaarden wordt voldaan:

Een schrijfbewerking omvat/impliceert een schrijfprobleem van j:true.
WiredTiger maakt een nieuw journaalbestand na elke 100 MB aan gegevens.
Na elke 100 milliseconden, afhankelijk van de storage.journal.commitIntervalMs.
In het geval van replicasetleden:
- Instantie van bewerkingen die wachten op oplog-vermeldingen, d.w.z. leesbewerkingen die worden uitgevoerd als onderdeel van causaal consistente sessies en het doorsturen van scanquery's tegen de oplog.
- Na elke batchtoepassing van de oplog-items in het geval van de secundaire leden.

In het geval van een harde afsluiting van mongod, als er schrijfbewerkingen aan de gang waren, kunnen updates verloren gaan, zelfs als de journaalrecords in de WiredTiger-buffers blijven.

Compressie van dagboekgegevens

Standaardinstelling in MongoDB zorgt ervoor dat de WiredTiger pittige compressie gebruikt voor de journaalgegevens. Dit kan worden gewijzigd, afhankelijk van welk compressie-algoritme u mogelijk wilt gebruiken met de instelling storage.wiredTiger.engineConfig.journalCompressor. Deze logrecords worden alleen gecomprimeerd als hun grootte groter is dan 128 bytes, wat de minimale logrecordgrootte van de WiredTiger is.

De grootte van een journaalbestand beperken

De maximale grootte van een journaalbestand is 100 MB en daarom wordt er een nieuw aangemaakt als het bestand deze limiet overschrijdt.

Nadat het journaalbestand is gebruikt voor herstel, of beter gezegd als er bestanden zijn die ouder zijn dan degene die kan worden gebruikt om te herstellen vanaf het laatste controlepunt, verwijdert de WiredTiger ze automatisch.

Pre-toewijzing

Journaalbestanden kunnen vooraf worden toegewezen met de WiredTiger-opslagengine als het mongod-proces bepaalt dat het efficiënter is om journaalbestanden vooraf toe te wijzen dan nieuwe aan te maken.

Hoe logboekregistratie werkt in de In-Memory Storage Engine

De In-memory Storage Engine werd vermeld als onderdeel van de algemene beschikbaarheid (GA) vanaf MongoDB Enterprise versie 3.2.6. Met deze opslagengine worden gegevens in het geheugen bewaard, dus geen aparte journaaltechniek. Als er schrijfbewerkingen zijn met een schrijfprobleem (j:true) zullen deze onmiddellijk worden bevestigd.

Voor een replicaset met een stemgerechtigd lid dat de in-memory storage-engine gebruikt, moet de writeConcernMajorityJournalDefault op false worden ingesteld. Anders, als dit is ingesteld op waar, zal de replicaset een opstartwaarschuwing loggen.

Als deze optie is ingesteld op 'false', wacht de database niet tot w:"meerderheid" wordt geschreven naar het on-disk journaal voordat de schrijfbewerkingen worden bevestigd. Het nadeel van deze benadering is dat schrijfbewerkingen met meerderheid mogelijk teruggedraaid kunnen worden in het geval van een tijdelijk verlies (zoals herstart of crash) van een meerderheid van knooppunten in een bepaalde replicaset.

Als u de MMapv1-opslagengine gebruikt, kan het vooraf toewijzen van een journaal worden uitgeschakeld met de optie --nopreallocation bij het starten van de mongod.

Met de WiredTiger-opslagengine, vanaf MongoDB versie 4.0 en hoger, is het niet mogelijk om de optie --nojournal of zelfs de storage.journal.enabled:false op te geven voor replicasetleden die de WiredTiger-opslagengine gebruiken.

Journaling beheren

Journaling uitschakelen

Journaling kan alleen worden uitgeschakeld voor zelfstandige implementaties en wordt niet aanbevolen voor productiesystemen. Voor MongoDB-versie 4.0 en hoger kan men noch de --nojournal-optie noch storage.journal.enabled:false specificeren wanneer er replicasetleden bij betrokken zijn die gebruikmaken van de WiredTiger-opslagengine.

Om journaalregistratie uit te schakelen, start u mongod met de --nojournal opdrachtregeloptie.

De journaalstatus volgen

Gebruik het commando db.serverStatus() dat wiredTiger.log teruggeeft om de statistieken over het journaal te krijgen.

Verkrijg bevestiging van toezegging

We gebruiken de write concern with j optie om commit-bevestiging te krijgen. {j:waar}. Logboekregistratie moet in dit geval zijn ingeschakeld, anders kan de mongod-instantie een fout produceren.

Als logboekregistratie is ingeschakeld, kan w:"meerderheid" j:true impliceren.

Voor een replicaset, wanneer j:true, vereist de installatie alleen de primaire om naar het journaal te schrijven, ongeacht de w: schrijfzorg.

Zelfs als de j:true is geconfigureerd voor een replicaset, kunnen er rollbacks optreden vanwege de primaire failover van de replicaset.

Onverwacht afsluiten van gegevensherstel

Alle journaalbestanden in de journaalmap worden opnieuw afgespeeld telkens wanneer MongoDB opnieuw opstart na een crash voordat de server wordt gedetecteerd. Aangezien deze bewerking zal worden vastgelegd in de loguitvoer, is het niet nodig --repair uit te voeren.

De WiredTiger Journal-compressor wijzigen

Snappy-compressor is het standaard algoritme voor compressie van het journaal. Je kunt dit echter veranderen, afhankelijk van de instelling van de mongod-instantie.

Voor een zelfstandige mongod-instantie:

Stel storage.wiredTiger.engineConfig.journalCompressor in op een nieuwe waarde om deze bij te werken. De meest geschikte manier om dit te doen is via het configuratiebestand, maar als u de opdrachtregelopties gebruikt, moet u de opdrachtregeloptie --wiredTigerJournalCompressor bijwerken tijdens het opnieuw opstarten.
Sluit de mongod-instantie af door verbinding te maken met een mongo-shell van de instantie en geef het commando:db.shutdownServer() of db.getSiblingDB('admin ).shutdownServer()
Start de mongod-instantie opnieuw:
1. Als u het configuratiebestand gebruikt, gebruik dan:mongod -f
2. Als u opdrachtregelopties gebruikt, werkt u de wiredTigerJournalCompressor bij:
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

Voor een lid van een replicaset:

Sluit de mongod-instantie af:db.shutdownServer() of db.getSiblingDB('admin).shutdownServer()
Breng de volgende wijzigingen aan in het configuratiebestand:
1. Stel storage.journal.enabled in op false.
2. Reageer op de replicatie-instellingen
3. Stel parameter disableLogicalSessionCacheRefresh in op true.

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

Start de mongod-instantie opnieuw:
1. Als je het configuratiebestand gebruikt, gebruik dan:mongod -f
2. Als u de opdrachtregelopties gebruikt:neem de --nojournal-optie op, verwijder alle replicatieopdrachtregelopties d.w.z. --replSet en stel parameter disableLogicalSessionCacheRefresh in op true
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

Sluit de mongod-instantie af:

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

Update het configuratiebestand ter voorbereiding op een herstart van het replicasetlid met de nieuwe journaalcompressor:verwijder de opslag. journal.enabled, verwijder de opmerkingen bij de replicatie-instellingen voor de implementatie, verwijder de optie disableLogicalSessionCacheRefresh en verwijder ten slotte storage.wiredTiger.engineConfig.journalCompressor.

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

Start de mongod-instantie opnieuw als lid van een replicaset

Als u het configuratiebestand gebruikt, gebruik dan:mongod -f
Als u de opdrachtregelopties gebruikt:verwijder de opties --nojournal en --wiredTigerJournalCompressor. Voeg de opdrachtregelopties voor replicatie toe en verwijder de parameter disableLogicalSessionCacheRefresh.

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

Conclusie

Om ervoor te zorgen dat MongoDB de duurzaamheid van de schrijfbewerking kan garanderen, wordt journaling gebruikt, waarbij gegevens van tevoren naar de schijf worden geschreven loggen. Zoveel als de WiredTiger-opslagengine (die de meeste voorkeur heeft) gegevens kan herstellen via de laatste controlepunten, als MongoDB onverwacht wordt afgesloten en journaling niet is ingeschakeld, wordt het herstellen van dergelijke gegevens onmogelijk. Als logboekregistratie is ingeschakeld, kan MongoDB de schrijfbewerkingen opnieuw toepassen bij het opnieuw opstarten en een consistente status behouden.