MongoDB använder en journal på disken för att garantera skrivoperationer och ge kraschsäkerhet. MongoDB skapar också en journal för varje skrivning som inkluderar den exakta diskplatsen och de byte som ändrades i skrivningen. Således, om du har en krasch i servern, kan journalen användas för att spela upp alla skrivningar som ännu inte har skrivits till datafilerna.
MongoDB använder minnesmappade filer för att skriva dina data till disken. Som standard rensas MongoDB-datafiler till disken var 60:e sekund. De använder också minnesmappade filer för journalen, och som standard töms journalen till disk var 100:e ms. Eftersom de slutliga datafilerna spolas till disken var 60:e sekund, behöver journalen inte spåra skrivningar i mer än en minut. Mer information om mekaniken i journalföringen finns i den officiella dokumentationen. För att förstå hur vykartläggningen fungerar mer i detalj kan du kolla in Kristinas blogg.
Journalist Skriv oro
>db.data.insert({"name":"testentry"});
>db.runCommand({"getLastError":1, "j":true});
När du aktiverar MongoDB-journalföring har du också möjligheten att ange ett skrivproblem i MongoDB om "Journaled" för dina MongoDB-operationer. Detta innebär att MongoDB bekräftar skrivoperationen först efter att ha bekräftat journalen. Detta har dock en nackdel - när du anger "j":true med getLastError, kommer MongoDB att vänta på cirka 1/3 av den interna journalbekräftelsen innan journaldata överförs. Standardintervallet för journalbekräftelse är 100 ms - så MongoDB väntar 30 ms och commiterar data. Detta betyder i huvudsak att på en enda tråd kan du bara få cirka 33,3 skrivningar/sekund, och den rekommenderade bästa praxisen är att batcha dina skrivningar. Till exempel, om du har 50 skrivningar, använd "j":true-inställningen endast vid den sista skrivningen - detta bekräftar att alla tidigare 50 skrivningar är gjorda.
Sammanfattning
Varje produktion MongoDB-instans bör köras med journalföring aktiverad. Om du inte har journalföring aktiverad och din server eller MongoDB-process kraschar, kommer MongoDB inte att kunna säkerställa dataintegritet. Du måste köra en "reparation" på databasen, som, beroende på mängden data, kan ta några timmar att slutföra. Stäng av den bara om du verkligen vet vad du gör. På ScaleGrid följer alla våra instanser MongoDB-konfigurationen för bästa praxis och har journalföring aktiverat som standard.