MongoDB bruger en journal på disken til at garantere skriveoperationer og give modstandsdygtighed over for nedbrud. MongoDB opretter også en journal for hver skrivning, der inkluderer den nøjagtige diskplacering og de bytes, der ændrede sig i skrivningen. Så hvis du har et nedbrud i serveren, kan journalen bruges til at afspille eventuelle skrivninger, der endnu ikke er skrevet til datafilerne.
MongoDB bruger hukommelseskortfiler til at skrive dine data til disk. Som standard skylles MongoDB-datafiler til disken hvert 60. sekund. De bruger også hukommelseskortfiler til journalen, og som standard tømmes journalen til disk hver 100 ms. Da de endelige datafiler skylles til disken hvert 60. sekund, behøver journalen ikke at spore skrivninger i mere end et minut. Se den officielle dokumentation for flere detaljer om mekanikken i journaliseringen. For at forstå, hvordan visningskortlægningen fungerer mere detaljeret, kan du tjekke Kristinas blog.
Journaling Skriv bekymring
>db.data.insert({"name":"testentry"});
>db.runCommand({"getLastError":1, "j":true});
Når du aktiverer MongoDB-journalføring, har du også mulighed for at angive en skrivebekymring i MongoDB af "Journaled" for dine MongoDB-operationer. Dette indebærer, at MongoDB først bekræfter skriveoperationen efter committing til journalen. Dette har dog en ulempe - når du angiver "j":true med getLastError, vil MongoDB vente på omkring 1/3 af den interne journalforpligtelse, før den commiterer journaldataene. Standard journal-commit-intervallet er 100ms - så MongoDB vil vente 30ms og forpligte dataene. Dette betyder i bund og grund, at du på en enkelt tråd kun kan få omkring 33,3 skrivninger/sekund, og den anbefalede bedste praksis er at batch dine skrivninger. Hvis du f.eks. har 50 skrivninger, skal du kun bruge "j":true-indstillingen ved den sidste skrivning - dette vil anerkende, at alle de foregående 50 skrivninger er udført.
Sammendrag
Hver produktion af MongoDB-forekomster bør køre med journalføring aktiveret. Hvis du ikke har journalføring aktiveret, og din server eller MongoDB-proces går ned, vil MongoDB ikke være i stand til at sikre dataintegritet. Du skal køre en "reparation" på databasen, som afhængigt af mængden af data kan tage et par timer at fuldføre. Slå det kun fra, hvis du virkelig ved, hvad du laver. Hos ScaleGrid følger alle vores forekomster MongoDB-konfigurationen af bedste praksis og har journalføring aktiveret som standard.