MongoDB Skriv bekymring:3 must-know advarsler

'Skriv bekymring' i MongoDB beskriver niveauet af skrivebekræftelse, du kan forvente af det. Det er en ret vigtig indstilling at huske i dine skriveoperationer, og dens adfærd er nyttig at forstå, især i distribuerede MongoDB-implementeringer (dvs. replikasæt og sharded clusters). I dette indlæg diskuterer vi 3 gotchas, når du bruger MongoDB skrive bekymring.

MongoDB skrive bekymring

MongoDBs dokumentation definerer skrivebekymring som "niveauet af bekræftelse, der anmodes fra MongoDB om skriveoperationer til en selvstændig mongod eller til replikasæt eller til sharded clusters. "

Simpelt sagt er en skrivebekymring en indikation af 'holdbarhed', der er sendt sammen med skriveoperationer til MongoDB. For at præcisere, lad os se på syntaksen:

{ 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.

* Du kan finde den detaljerede syntaks i dokumentationen til Write Concern Specification.

* Lær mere om de forskellige "tags", du kan bruge til almindelige skrivebekymringsværdier, i vores Understanding Durability &Write Safety in MongoDB blog.

Eksempel:

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

Ovenstående indstiks skrivebekymring kan læses som følger:  anerkend denne skrivning, når "mindst 2 medlemmer af replikasættet har skrevet det til deres journaler inden for 5000 msek eller returnerer en fejl '. En skrivebekymringsværdi for optionen var majoritet, hvilket betyder "ranmoder om anerkendelse af, at skriveoperationer har forplantet sig til flertallet af afstemningsknudepunkter, inklusive de primære. "

Vigtigheden af ​​skrivebekymring er tydelig. Forøgende værdier af w øger latenstiden for skrivninger, mens det også mindsker deres sandsynlighed for at fare vild. Valg af de korrekte værdier for skriveproblemer afhænger af latens- og holdbarhedskravene for de skrivninger, der udføres.

Med det som baggrund for, hvad en skrivebekymring er, lad os gå videre til de tre forbehold, der skal huskes, når du bruger skrivebekymring.

ADVARSEL 1: Indstilling af skrivebekymring på replikasæt uden wtimeout kan forårsage, at skrivninger blokeres på ubestemt tid

Majoritetsdefinitionen (gælder MongoDB 3.0 og frem) ovenfor angiver, at der anmodes om anerkendelse fra et flertal af "afstemningsknuderne". Bemærk at “Hvis du ikke angiver wtimeout mulighed og niveauet af skriveproblemer er uopnåeligt, vil skriveoperationen blokere på ubestemt tid. "

Dette kan have uventede konsekvenser, for eksempel overvej et 2+1 replikasæt (dvs. en primær, en sekundær og en arbiter). Hvis din eneste læste replika går ned, så vil alle skrivninger med en skrivebekymring med mulighed for "flertal" blokere på ubestemt tid. Det samme vil ske, hvis w-indstillingen er sat til 2. Et andet ekstremt eksempel er i tilfælde af et 3+2 replikasæt (primært, 2 sekundære og 2 arbitere, ikke en anbefalet konfiguration). Alle "majority"-skrivninger vil blokere, selvom en enkelt dataknude ikke er tilgængelig, da majoritetstallet, i dette tilfælde, er 3.

Den enkleste måde at afhjælpe dette problem på er altid at angive en wtimeout-værdi, så forespørgslen kan timeout, hvis skriveproblemet ikke kan håndhæves. Men i tilfælde af sådanne timeout-fejl fortryder MongoDB ikke allerede vellykkede skrivninger, der er foretaget til nogle af medlemmerne, før timeouten indtraf.

Der er i øjeblikket heller ingen indstilling til at sikre, at en skrivning når de fleste noder, der i øjeblikket er tilgængelige, så vær forsigtig med at indstille værdien af ​​skrivebekymring w baseret på den ønskede topologi holdbarhed og tilgængelighed.

ADVARSEL 2: Du kan miste data selv med w:majoritet

Det virker intuitivt, at når en skrivning først er blevet anerkendt af flertallet af stemmeberettigede medlemmer, er dens holdbarhed garanteret. Det er dog ikke tilfældet! Husk, at når j-indstillingen er uspecificeret, bekræftes en skrivning lige efter, at den er blevet skrevet til hukommelsen.

Så en sådan skrivning kan gå tabt, hvis et freak strømafbrydelse fjerner størstedelen af ​​de noder, som skrivningen havde forplantet sig til (og før syncPeriodSecs, dvs. før den kunne skylles til disk).

For at sikre holdbarheden af ​​skrivninger er det bedst ikke at slå journalføring fra på din database og indstille j-indstillingen til sand. Faktisk starter MongoDB 3.6, --nojournal flag er blevet forældet for replikasætmedlemmer, der bruger WiredTiger-lagringsmotoren.

Med en w-værdi på "majority" og j-indstillingen uspecificeret på et replikasæt, afhænger den nøjagtige holdbarhedsadfærd af værdien af ​​replikasættets konfiguration writeConcernMajorityJournalDefault. Når den er indstillet til sand (og når journalføring er aktiveret), anerkender den skrivninger, efter at de er blevet skrevet til journalerne for et flertal af stemmeberettigede medlemmer.

Bortset:Selv med journalføring slået til, kan dine skrivninger stadig gå tabt på MMAPv1-lagringsmotoren, hvis der opstår et udfald inden for commitIntervalMs varighed. WiredTiger-lagringsmotoren tvinger på den anden side en synkronisering af journalfiler, når den modtager en skrivning med j-indstillingen sat til sand. Og selv med j sat til false, kan en anerkendt "majority"-skrivning til en seneste WiredTiger-baseret implementering kun gå tabt, når størstedelen af ​​dataknuderne går ned samtidigt.

ADVARSEL 3: w:0 mens indstilling af j:sand forbedrer ikke skriveydeevnen

Dette er nemt nok at ræsonnere, når du først tænker over det, men lige så nemt at glemme. Indstilling af w option til 0 gøres normalt for at skrive til databasen på en "brand-og-glem" måde - når du har en rimelig grad af tillid til databasens infrastruktur og bekymrer dig mere om latency end holdbarheden af ​​hver skrivning. Men hvis du indstiller j-indstillingen til sand, vil din w-indstilling effektivt blive tilsidesat, da databasen vil sikre, at skrivningen skrives til journalen på disken, før den returneres.

Hvis du bruger skriveproblemer til at garantere succesen med dine skriveoperationer, skal du sørge for at huske disse tre afgørende forbehold! Vi er her for at hjælpe, så du er velkommen til at kontakte os med spørgsmål via Twitter eller via e-mail.