Håndtering af journalføring i MongoDB

MongoDB kan ligesom enhver anden database fejle, når en skriveoperation udføres. I så fald har vi brug for en strategi, der vil holde operationen et sted, så databasen kan genoptages, når den er gendannet tilbage til drift.

I MongoDB bruger vi journalføring, hvorved der er en skrive-forud-logning til journalfiler på disken for at holde dataene tilgængelige i tilfælde af fejl. WiredTiger-lagringsmotoren kan bruge kontrolpunkter til at give en ensartet visning af data på disken og tillade MongoDB at gendanne fra det sidste kontrolpunkt, men kun hvis det ikke forsvandt uventet. Ellers skal journalisering være aktiveret for de oplysninger, der opstod under det sidste kontrolpunkt, for at gendanne sådanne data.

Proceduren for gendannelsesprocessen er, at:databasen vil kigge i datafilerne for at finde identifikatoren for det sidste kontrolpunkt, bruge denne identifikator til at søge i journalfilerne efter den post, der matcher den og Anvend derefter handlingerne i journalfilerne siden sidste kontrolpunkt.

Sådan fungerer journalføring i WiredTiger Storage Engine

For hver klient, der starter en skriveoperation, opretter WiredTiger en journalpost, der er sammensat af interne skriveoperationer, der blev udløst af den indledende skrivning. Overvej et dokument i en samling, der skal opdateres, og vi forventer, at dets indeks også bliver ændret. WiredTigeren vil oprette en enkelt journalpost, der vil inkorporere opdateringsoperationen og tilsvarende indeksændringer.

Denne post vil blive gemt i en buffer i hukommelsen, hvis maksimale kapacitet er 128 kB. Lagermotoren synkroniserer derefter disse bufferlagrede journalposter til disk, når et af følgende er opfyldt:

En skriveoperation inkluderer/antyder en skrivebekymring om j:sand.
WiredTiger opretter en ny journalfil, som er efter hver 100 MB data.
Efter hvert 100 millisekund afhængigt af storage.journal.commitIntervalMs.
I tilfælde af replikasætmedlemmer:
- Forekomst af operationer, der venter på oplog-indgange, dvs. læsehandlinger udført som en del af kausalt konsistente sessioner og videresende scanningsforespørgsler mod oploggen.
- Efter hver batch-anvendelse af oplog-posterne i tilfælde af de sekundære medlemmer.

I tilfælde af en hård nedlukning af mongod, hvis skriveoperationer var i gang, kan opdateringer gå tabt, selvom journalposterne forbliver i WiredTiger-bufferne.

Journaldatakomprimering

Standardindstillingen i MongoDB instruerer WiredTiger til at bruge hurtig komprimering til journaldata. Dette kan ændres afhængigt af hvilken komprimeringsalgoritme du måtte ønske ved at bruge storage.wiredTiger.engineConfig.journalCompressor indstillingen. Disse logposter komprimeres kun, hvis deres størrelse er større end 128 bytes, hvilket er den mindste logpoststørrelse for WiredTiger.

Begrænsning af størrelsen af en journalfil

Den maksimale størrelse af en journalfil er 100 MB, og hvis filen overskrider denne grænse, vil en ny blive oprettet.

Efter at journalfilen er blevet brugt til gendannelse, eller rettere, der er filer, der er ældre end den, der kan bruges til at genoprette fra det sidste kontrolpunkt, fjerner WiredTiger dem automatisk.

Forudtildeling

Journalfiler kan forhåndstildeles med WiredTiger-lagringsmotoren, hvis mongod-processen bestemmer, at det er mere effektivt at forudallokere journalfiler end at oprette nye.

Hvordan journalføring fungerer i In-Memory Storage Engine

Lagringsmotoren i hukommelsen blev angivet som en del af den generelle tilgængelighed (GA) startende med MongoDB Enterprise version 3.2.6. Med denne lagringsmotor opbevares data i hukommelsen og derfor ingen separat journaliseringsteknik. Hvis der er nogen skrivehandlinger med en skrivebekymring (j:sand), vil de straks blive bekræftet.

For et replikasæt med et stemmeberettiget medlem , der bruger lagermotoren i hukommelsen, skal man indstille writeConcernMajorityJournalDefault til false. Ellers, hvis dette er sat til sand, vil replikasættet logge en startadvarsel.

Når denne indstilling er indstillet til falsk, vil databasen ikke vente på, at w:"majority"-skrivning bliver skrevet til journalen på disken, før den bekræfter skrivningerne. Ulempen ved denne tilgang er, at skriveoperationer med flertallet kan rulle tilbage i tilfælde af et forbigående tab (såsom genstart eller nedbrud) af et flertal af noder i et givet replikasæt.

Hvis du bruger MMapv1-lagringsmotoren, kan journal-for-allokering deaktiveres ved at bruge --nopreallocation-indstillingen, når du starter mongod.

Med WiredTiger-lagringsmotoren, fra MongoDB version 4.0 og opefter, er det ikke muligt at angive --nojournal-indstillingen eller endda storage.journal.enabled:false for replikasætmedlemmer, der bruger WiredTiger-lagringsmotoren.

Administration af journalføring

Deaktivering af journalføring

Journaling kan kun deaktiveres for selvstændige installationer, og det anbefales ikke til produktionssystemer. For MongoDB version 4.0 og opefter kan man ikke angive hverken --nojournal-indstillingen eller storage.journal.enabled:false, når replikasætmedlemmer, der bruger WiredTiger-lagringsmotor, er involveret.

For at deaktivere journalføring skal du starte mongod med kommandolinjeindstillingen --nojournal.

Overvåg journalstatus

For at få statistik over journalen brug kommandoen db.serverStatus(), som returnerer wiredTiger.log.

Få forpligtelsesbekræftelse

Vi bruger muligheden for at skrive bekymring med j for at få bekræftelse af forpligtelse. {j:sandt}. Journalføring skal være aktiveret i dette tilfælde, ellers kan mongod-forekomsten producere en fejl.

Hvis journalføring er aktiveret, w:"majority" kan dette betyde j:true.

For et replikasæt, når j:sand, kræver opsætningen kun den primære til at skrive til journalen, uanset w: skriveproblemet.

Men selv hvis j:true er konfigureret til et replikasæt, kan der dog forekomme tilbagerulninger på grund af replikasæts primære failover.

Uventet gendannelse af nedlukningsdata

Alle journalfiler i journalbiblioteket afspilles igen, når MongoDB genstarter fra et nedbrud, før serveren registreres. Da denne operation vil blive registreret i log-outputtet, vil der ikke være behov for at køre --repair.

Ændring af WiredTiger Journal Compressor

Snappy-kompressor er standard-algoritmen for komprimering for journalen. Men man kan ændre dette afhængigt af mongod-instansens opsætning.

For en enkeltstående mongod-forekomst:

Indstil storage.wiredTiger.engineConfig.journalCompressor til en ny værdi for at opdatere den. Den mest passende måde at gøre dette på er gennem konfigurationsfilen, men hvis du bruger kommandolinjeindstillingerne, skal du opdatere --wiredTigerJournalCompressor kommandolinjeindstillingen under genstart.
Luk mongod-forekomsten ved at oprette forbindelse til en mongo-shell af forekomsten og udsend kommandoen:db.shutdownServer() eller db.getSiblingDB('admin ).shutdownServer()
Genstart mongod-forekomsten:
1. Hvis du bruger konfigurationsfilen, skal du bruge:mongod -f
2. Hvis du bruger kommandolinjeindstillinger, skal du opdatere wiredTigerJournalCompressor:
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

For et replikasætmedlem:

Luk mongod-forekomsten:db.shutdownServer() eller db.getSiblingDB(‘admin).shutdownServer()
Foretag følgende ændringer i konfigurationsfilen:
1. Sæt storage.journal.enabled til false.
2. Kommenter replikeringsindstillingerne
3. Sæt parameter disableLogicalSessionCacheRefresh til sand.

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

Genstart mongod-forekomsten:
1. Hvis du bruger konfigurationsfilen, skal du bruge:mongod -f
2. Hvis du bruger kommandolinjeindstillingerne:inkludere --nojournal-indstillingen, fjern eventuelle replikeringskommandolinjeindstillinger dvs. --replSæt og indstil parameter disableLogicalSessionCacheRefresh til sand
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

Luk mongod-forekomsten:

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

Opdater konfigurationsfilen for at forberede en genstart af replikasætmedlemmet med den nye journalkompressor:Fjern lageret. journal.enabled, fjern kommentarer til replikeringsindstillingerne for implementeringen, fjern disableLogicalSessionCacheRefresh-indstillingen og fjern til sidst storage.wiredTiger.engineConfig.journalCompressor.

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

Genstart mongod-instansen som et replikasætmedlem

Hvis du bruger konfigurationsfilen, skal du bruge:mongod -f
Hvis du bruger kommandolinjeindstillingerne:fjern --nojournal og --wiredTigerJournalCompressor muligheder. Inkluder kommandolinjeindstillingerne for replikering, og fjern parameteren disableLogicalSessionCacheRefresh.

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

Konklusion

For at MongoDB kan garantere en skriveoperations holdbarhed, bruges journalføring, hvorved data skrives til on-disk gennem ahead logning. Så meget som WiredTiger-lagringsmotoren (som er den mest foretrukne) kan gendanne data gennem de sidste kontrolpunkter, hvis MongoDB afsluttes uventet, og journalføring ikke var aktiveret, bliver det umuligt at gendanne sådanne data. Ellers, hvis journalføring er aktiveret, kan MongoDB genanvende skrivehandlingerne ved genstart og opretholde en konsistent tilstand.