sql >> Database >  >> NoSQL >> MongoDB

Moet u MongoDB-journaling inschakelen?

MongoDB gebruikt een on-disk journaal om schrijfbewerkingen te garanderen en crashbestendigheid te bieden. MongoDB maakt ook een journaal voor elke schrijfbewerking met de exacte schijflocatie en de bytes die tijdens het schrijven zijn gewijzigd. Dus als je een crash in de server hebt, kan het journaal worden gebruikt om alle schrijfbewerkingen die nog niet naar de gegevensbestanden zijn geschreven, opnieuw af te spelen.

MongoDB gebruikt geheugen toegewezen bestanden om uw gegevens naar schijf te schrijven. Standaard worden MongoDB-gegevensbestanden elke 60 seconden naar schijf gespoeld. Ze gebruiken ook geheugen toegewezen bestanden voor het journaal, en standaard wordt het journaal elke 100 ms naar de schijf gewist. Aangezien de laatste gegevensbestanden elke 60 seconden naar de schijf worden gespoeld, hoeft het journaal de schrijfbewerkingen niet langer dan één minuut bij te houden. Raadpleeg de officiële documentatie voor meer informatie over de werking van het journaal. Om meer in detail te begrijpen hoe de view mapping werkt, kun je Kristina's blog bekijken.

Journaling Write Concern

>db.data.insert({"name":"testentry"});
>db.runCommand({"getLastError":1, "j":true});

Als je MongoDB-journaling inschakelt, heb je ook de mogelijkheid om een ​​schrijfprobleem op te geven in MongoDB van 'Journaled' voor je MongoDB-bewerkingen. Dit houdt in dat MongoDB de schrijfbewerking pas bevestigt na het vastleggen in het journaal. Dit heeft echter een nadeel:wanneer u "j":true opgeeft met getLastError, wacht MongoDB ongeveer 1/3 van de interne commit van het journaal voordat de journaalgegevens worden vastgelegd. Het standaardinterval voor het vastleggen van een journaal is 100 ms - dus MongoDB wacht 30 ms en legt de gegevens vast. Dit betekent in wezen dat u op een enkele thread slechts ongeveer 33,3 schrijfbewerkingen per seconde kunt krijgen, en de aanbevolen beste praktijk is om uw schrijfbewerkingen te batchen. Als u bijvoorbeeld 50 schrijfbewerkingen hebt, gebruikt u de instelling "j":true alleen bij de laatste schrijfbewerking - dit bevestigt dat alle voorgaande 50 schrijfbewerkingen zijn voltooid.

Samenvatting

Elke productie-MongoDB-instantie zou moeten draaien met journaling ingeschakeld. Als je journaling niet hebt ingeschakeld en je server of MongoDB-proces crasht, kan MongoDB de gegevensintegriteit niet garanderen. U moet een "reparatie" -bewerking op de database uitvoeren, die, afhankelijk van de hoeveelheid gegevens, enkele uren kan duren om te voltooien. Schakel het alleen uit als u echt weet wat u doet. Bij ScaleGrid volgen al onze instanties de MongoDB-configuratie met best practices en is logboekregistratie standaard ingeschakeld.


  1. Hoe kan ik op afstand de gegevens in mijn RedisCloud DB's inspecteren?

  2. Redis-sleutelontwerp voor realtime voorraadtoepassing

  3. Express Node.JS - Redis-callback ontvangen, beloften uitvoeren

  4. Waarom gebruikt mangoest schema als het voordeel van mongodb zou moeten zijn dat het schemaloos is?