Hantera journalföring i MongoDB

MongoDB precis som vilken annan databas som helst kan misslyckas när en skrivoperation utförs. I så fall behöver vi en strategi som kommer att behålla operationen någonstans så att databasen kan återupptas när den återställs till drift.

I MongoDB använder vi journalisering där det sker en skrivförut-loggning till journalfiler på disken för att hålla data tillgänglig i händelse av fel. WiredTiger-lagringsmotorn kan använda kontrollpunkter för att ge en konsekvent bild av data på disken och tillåta MongoDB att återhämta sig från den senaste kontrollpunkten men bara om den inte avslutades oväntat. Annars, för informationen som inträffade under den senaste kontrollpunkten, måste journalföring ha aktiverats för att återställa sådana data.

Proceduren för återställningsprocessen är att:databasen kommer att titta in i datafilerna för att hitta identifieraren för den senaste kontrollpunkten, använd denna identifierare för att söka i journalfilerna efter posten som matchar den och tillämpa sedan operationerna i journalfilerna sedan den senaste kontrollpunkten.

Hur journalföring fungerar i WiredTiger Storage Engine

För varje klient som initierar en skrivoperation skapar WiredTiger en journalpost som består av interna skrivoperationer som utlöstes av den första skrivningen. Överväg ett dokument i en samling som ska uppdateras och vi förväntar oss att dess index också ändras. WiredTiger kommer att skapa en enda journalpost som innehåller uppdateringsoperationen och motsvarande indexändringar.

Denna post kommer att lagras i en minnesbuffert vars maximala kapacitet är 128kB. Lagringsmotorn synkroniserar sedan dessa buffrade journalposter till disk när något av följande är uppfyllt:

En skrivoperation inkluderar/implicerar ett skrivproblem av j:true.
WiredTiger skapar en ny journalfil som är efter varje 100 MB data.
Efter var 100:e millisekund beroende på storage.journal.commitIntervalMs.
Vid replikuppsättningsmedlemmar:
- Förekomst av operationer som väntar på oplog-poster, dvs. läsoperationer som utförs som en del av kausalt konsekventa sessioner och vidarebefordra skanningsfrågor mot oploggen.
- Efter varje batch-applicering av oplog-posterna för de sekundära medlemmarna.

I händelse av en hård avstängning av mongod, om skrivoperationer pågick, kan uppdateringar gå förlorade även om journalposterna finns kvar i WiredTiger-buffertarna.

Komprimering av journaldata

Standardinställningen i MongoDB styr WiredTiger att använda snabb komprimering för journaldata. Detta kan ändras beroende på vilken komprimeringsalgoritm du kanske vill använda med inställningen storage.wiredTiger.engineConfig.journalCompressor. Dessa loggposter komprimeras endast om deras storlek är större än 128 byte, vilket är den minsta loggpoststorleken för WiredTiger.

Begränsa storleken på en journalfil

Den maximala storleken på en journalfil är 100 MB och därför kommer en ny att skapas om filen överskrider denna gräns.

Efter att journalfilen har använts vid återställning eller snarare finns det filer som är äldre än den som kan användas för att återställa från den senaste kontrollpunkten, tar WiredTiger automatiskt bort dem.

Förtilldelning

Journalfiler kan förallokeras med WiredTiger-lagringsmotorn om mongod-processen bestämmer att det är mer effektivt att förallokera journalfiler än att skapa nya.

Hur journalföring fungerar i In-Memory Storage Engine

Lagringsmotorn i minnet angavs som en del av den allmänna tillgängligheten (GA) från och med MongoDB Enterprise version 3.2.6. Med denna lagringsmotor hålls data i minnet och därför ingen separat journaliseringsteknik. Om det finns några skrivoperationer med skrivproblem (j:sant) kommer de omedelbart att bekräftas.

För en replikuppsättning med en röstande medlem som använder lagringsmotorn i minnet måste man ställa in writeConcernMajorityJournalDefault på false. I annat fall, om detta är inställt på sant, kommer replikuppsättningen att logga en startvarning.

När det här alternativet är inställt på false, kommer databasen inte att vänta på att w:"majority"-skrivning skrivs till journalen på disken innan skrivningarna bekräftas. Nackdelen med detta tillvägagångssätt är att skrivoperationer med majoritet kan rulla tillbaka i händelse av en övergående förlust (som omstart eller krasch) av de flesta noder i en given replikuppsättning.

Om du använder MMapv1-lagringsmotorn kan journalfördelning inaktiveras med alternativet --nopreallocation när du startar mongod.

Med WiredTiger-lagringsmotorn, från MongoDB version 4.0 och uppåt, är det inte möjligt att specificera --nojournal-alternativet eller ens storage.journal.enabled:false för replikuppsättningsmedlemmar som använder WiredTiger-lagringsmotorn.

Hantera journalföring

Inaktivera journalföring

Journaling kan endast inaktiveras för fristående distributioner och det rekommenderas inte för produktionssystem. För MongoDB version 4.0 och uppåt kan man inte specificera varken --nojournal-alternativet eller storage.journal.enabled:false när replikuppsättningsmedlemmar som använder WiredTiger-lagringsmotorn är inblandade.

För att inaktivera journalföring starta mongod med kommandoradsalternativet --nojournal.

Övervaka journalstatus

För att få statistik på journalen använd kommandot db.serverStatus() som returnerar wiredTiger.log.

Få bekräftelse på åtagande

Vi använder alternativet skrivproblem med j för att få bekräftelse. {j:sant}. Journalföring måste vara aktiverat i detta fall annars kan mongod-instansen skapa ett fel.

Om journalföring är aktiverat, w:"majority" kan detta innebära j:true.

För en replikuppsättning, när j:true, kräver installationen endast den primära för att skriva till journalen, oavsett w:-skrivproblemet.

Men även om j:true är konfigurerad för en replikuppsättning, kan återställningar inträffa på grund av replikuppsättningens primära failover.

Oväntad avstängningsdataåterställning

Alla journalfiler i journalkatalogen spelas upp igen när MongoDB startar om från en krasch innan servern upptäcks. Eftersom denna operation kommer att registreras i loggutgången, behöver du inte köra --repair.

Ändra WiredTiger Journal Compressor

Snappy compressor är standardalgoritmen för komprimering för journalen. Men man kan ändra detta beroende på mongod-instansens inställning.

För en fristående mongod-instans:

Ställ in storage.wiredTiger.engineConfig.journalCompressor till ett nytt värde för att uppdatera det. Det lämpligaste sättet att göra detta är genom konfigurationsfilen, men om du använder kommandoradsalternativen måste du uppdatera kommandoradsalternativet --wiredTigerJournalCompressor under omstart.
Stäng av mongod-instansen genom att ansluta till ett mongo-skal för instansen och utfärda kommandot:db.shutdownServer() eller db.getSiblingDB('admin ).shutdownServer()
Starta om mongod-instansen:
1. Om du använder konfigurationsfilen, använd:mongod -f
2. Om du använder kommandoradsalternativ, uppdatera wiredTigerJournalCompressor:
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

För en replikuppsättningsmedlem:

Stäng av mongod-instansen:db.shutdownServer() eller db.getSiblingDB(‘admin).shutdownServer()
Gör följande ändringar i konfigurationsfilen:
1. Sätt storage.journal.enabled till false.
2. Kommentera replikeringsinställningarna
3. Ställ in parametern disableLogicalSessionCacheRefresh till true.

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

Starta om mongod-instansen:
1. Om du använder konfigurationsfilen, använd:mongod -f
2. Om du använder kommandoradsalternativen:inkludera alternativet --nojournal, ta bort alla kommandoradsalternativ för replikering dvs. --replSätt in och ställ in parameter disableLogicalSessionCacheRefresh till true
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

Stäng av mongod-instansen:

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

Uppdatera konfigurationsfilen för att förbereda för en omstart av replikuppsättningsmedlemmen med den nya journalkompressorn:Ta bort lagringen. journal.enabled, avkommentera replikeringsinställningarna för distributionen, ta bort alternativet disableLogicalSessionCacheRefresh och slutligen ta bort storage.wiredTiger.engineConfig.journalCompressor.

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

Starta om mongod-instansen som en replikuppsättningsmedlem

Om du använder konfigurationsfilen, använd:mongod -f
Om du använder kommandoradsalternativen:ta bort alternativen --nojournal och --wiredTigerJournalCompressor. Inkludera kommandoradsalternativen för replikering och ta bort parametern disableLogicalSessionCacheRefresh.

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

Slutsats

För att MongoDB att garantera en skrivoperations hållbarhet, används journalisering där data skrivs till på disken framöver skogsavverkning. Så mycket som WiredTiger-lagringsmotorn (som är den mest föredragna) kan återställa data genom de sista kontrollpunkterna, om MongoDB avslutas oväntat och journalföring inte var aktiverad, blir det omöjligt att återställa sådan data. Annars, om journalföring är aktiverat, kan MongoDB använda skrivoperationerna på nytt vid omstart och behålla ett konsekvent tillstånd.