MongoDB Schrijfzorg:3 Must-Know Caveats

'Schrijfprobleem' in MongoDB beschrijft het niveau van schrijfbevestiging dat je ervan kunt verwachten. Het is een nogal belangrijke instelling om te onthouden bij uw schrijfbewerkingen en het gedrag ervan is nuttig om te begrijpen, vooral in gedistribueerde MongoDB-implementaties (d.w.z. replicasets en sharded-clusters). In dit bericht bespreken we 3 valkuilen bij het gebruik van MongoDB-schrijfproblemen.

MongoDB Schrijfzorg

MongoDB's documentatie definieert schrijfzorg als "het niveau van bevestiging dat door MongoDB wordt gevraagd voor schrijfbewerkingen naar een zelfstandige mongod of voor replicasets of naar shard-clusters. “

Eenvoudig gezegd, een schrijfprobleem is een indicatie van 'duurzaamheid' die samen met schrijfbewerkingen wordt doorgegeven aan MongoDB. Laten we ter verduidelijking naar de syntaxis kijken:

{ w: <value>, j: <boolean>, wtimeout: <number> }
Where*,
 w can be an integer | "majority" | , it represents the number of members that must acknowledge the write. Default value is 1.
 j Requests that a write be acknowledged after it is written to the on-disk journal as opposed to just the system memory. Unspecified by default.
wtimeout specifies timeout for the applying the write concern. Unspecified by default.

* U kunt de gedetailleerde syntaxis vinden in de documentatie bij Write Concern Specification.

* Lees meer over de verschillende "tags" die u kunt gebruiken voor veelvoorkomende schrijfproblemen in ons blog Inzicht in duurzaamheid en schrijfveiligheid in MongoDB.

Voorbeeld:

db.inventory.insert(
    { sku: "abcdxyz", qty : 100, category: "Clothing" },
    { writeConcern: { w: 2, j: true, wtimeout: 5000 } }
)

Het schrijfprobleem van de bovenstaande bijlage kan als volgt worden gelezen:  bevestig dit schrijven wanneer 'ten minste 2 leden van de replicaset het binnen 5000 msec naar hun journaal hebben geschreven of een fout retourneren '. Een waarde voor schrijfzorg voor de optie was meerderheid, wat betekent dat 'rvraagt ​​om bevestiging dat schrijfbewerkingen zijn doorgegeven aan de meerderheid van de stemknooppunten, inclusief de primaire. “

Het belang van schrijfzorg is duidelijk. Door de waarden van w te verhogen, neemt de latentie van schrijfbewerkingen toe, terwijl ook de kans op verdwalen wordt verkleind. Het kiezen van de juiste waarden voor schrijfproblemen hangt af van de latentie- en duurzaamheidsvereisten van de schrijfbewerkingen die worden uitgevoerd.

Met dat als achtergrond over wat een schrijfprobleem is, gaan we verder met de drie waarschuwingen die we moeten onthouden bij het gebruik van schrijfproblemen.

CAVEAT 1: Als u schrijfproblemen instelt op replicasets zonder wtimeout, kunnen schrijfacties voor onbepaalde tijd worden geblokkeerd

De meerderheidsdefinitie (van toepassing op MongoDB 3.0 en hoger) hierboven stelt dat bevestiging wordt gevraagd van een meerderheid van de "stemknooppunten". Merk op dat “Als u de wtimeout . niet opgeeft optie en het niveau van schrijfzorg onbereikbaar is, wordt de schrijfbewerking voor onbepaalde tijd geblokkeerd. "

Dit kan onverwachte gevolgen hebben, denk bijvoorbeeld aan een 2+1 replicaset (d.w.z. een primaire, een secundaire en een arbiter). Als uw enige leesreplica uitvalt, worden alle schrijfbewerkingen met een schrijfzorg met de optie "meerderheid" voor onbepaalde tijd geblokkeerd. Hetzelfde zal gebeuren als de w optie is ingesteld op 2. Een ander extreem voorbeeld is in het geval van een 3+2 replicaset (primair, 2 secondaries en 2 arbiters, geen aanbevolen configuratie). Alle 'meerderheid'-schrijfacties worden geblokkeerd, zelfs als een enkel gegevensknooppunt niet beschikbaar is, aangezien het meerderheidsgetal, in dit geval 3 is.

De eenvoudigste manier om dit probleem op te lossen, is door altijd een wtimeout-waarde op te geven, zodat de query een time-out kan krijgen als het schrijfprobleem niet kan worden afgedwongen. In het geval van dergelijke time-outfouten maakt MongoDB echter geen reeds succesvolle schrijfacties ongedaan die aan sommige leden zijn gemaakt voordat de time-out optrad.

Er is momenteel ook geen instelling om ervoor te zorgen dat een schrijfactie de meerderheid van de knooppunten bereikt die momenteel bereikbaar zijn, dus wees voorzichtig met het instellen van de waarde van schrijfzorg w op basis van de gewenste topologie duurzaamheid en beschikbaarheid.

VOORZICHTIG 2: Je kunt gegevens kwijtraken, zelfs met w:meerderheid

Het lijkt intuïtief dat zodra een schrijven is erkend door de meerderheid van de stemgerechtigde leden, de duurzaamheid ervan gegarandeerd is. Dat is echter niet het geval! Onthoud dat wanneer de j-optie niet gespecificeerd is, een schrijfbewerking wordt bevestigd direct nadat deze naar het geheugen is geschreven.

Zo'n schrijfbewerking kan dus verloren gaan als een buitenissige stroomstoring de meerderheid van de knooppunten uitschakelt waarnaar de schrijfactie was gepropageerd (en vóór syncPeriodSecs, d.w.z. voordat het kon worden weggespoeld naar schijf).

Om de duurzaamheid van schrijven te garanderen, is het het beste om journaling in uw database niet uit te schakelen en de j-optie in te stellen op true. In feite, vanaf MongoDB 3.6, de --nojournal vlag is verouderd voor leden van replicasets die de WiredTiger-opslagengine gebruiken.

Met een w-waarde van "majority" en de j-optie die niet is gespecificeerd op een replicaset, hangt het exacte duurzaamheidsgedrag af van de waarde van de replicasetconfiguratie writeConcernMajorityJournalDefault. Indien ingesteld op true (en wanneer journaling is ingeschakeld), bevestigt het schrijfacties nadat ze zijn geschreven naar de journals van een meerderheid van de stemgerechtigde leden.

Terzijde:zelfs als logboekregistratie is ingeschakeld, kunnen uw schrijfbewerkingen nog steeds verloren gaan op de MMAPv1-opslagengine als er een storing optreedt binnen de duur van de commitIntervalMs. De WiredTiger-opslagengine daarentegen dwingt een synchronisatie van journaalbestanden af ​​wanneer deze een schrijfbewerking ontvangt met de j-optie ingesteld op true. En zelfs als j is ingesteld op false, kan een erkende 'meerderheid'-schrijfactie naar een nieuwste op WiredTiger gebaseerde implementatie alleen verloren gaan wanneer de meeste gegevensknooppunten tegelijkertijd crashen.

CAVEAT 3: w:0 bij instelling j:true verbetert de schrijfprestaties niet

Dit is gemakkelijk genoeg om te redeneren als je erover nadenkt, maar even gemakkelijk te vergeten. Het instellen van w-optie op 0 wordt meestal gedaan om op een "vuur-en-vergeet"-manier naar de database te schrijven - wanneer u redelijk veel vertrouwen hebt in de database-infrastructuur en meer geeft om latentie dan om de duurzaamheid van elke schrijfactie. Als u echter de j-optie instelt op true, wordt uw w-optie in feite overschreven, omdat de database ervoor zorgt dat het schrijven naar het on-disk-journaal wordt geschreven voordat het terugkeert.

Als je schrijfproblemen gebruikt om het succes van je schrijfbewerkingen te garanderen, onthoud dan deze drie cruciale waarschuwingen! We zijn hier om te helpen, dus voel je vrij om contact op te nemen met eventuele vragen via Twitter of per e-mail.