sql >> Databasteknik >  >> NoSQL >> MongoDB

MongoDB Skriv oro:3 måste-känna varningar

"Skriv oro" i MongoDB beskriver nivån på skrivbekräftelse du kan förvänta dig av den. Det är en ganska viktig inställning att komma ihåg i dina skrivoperationer och dess beteende är användbart att förstå, särskilt i distribuerade MongoDB-distributioner (dvs. replikuppsättningar och fragmenterade kluster). I det här inlägget diskuterar vi 3 gotchas när du använder MongoDB skrivproblem.

MongoDB Skriv oro

MongoDB:s dokumentation definierar skrivproblem som "nivån av bekräftelse som begärs från MongoDB för skrivoperationer till en fristående mongod eller till replikuppsättningar eller till fragmenterade kluster. "

Enkelt uttryckt är ett skrivproblem en indikation på "hållbarhet" som skickas tillsammans med skrivoperationer till MongoDB. För att förtydliga, låt oss titta på syntaxen:

{ 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 hitta den detaljerade syntaxen i dokumentationen för Write Concern Specification.

* Läs mer om de olika "taggarna" som du kan använda för vanliga skrivproblem i vår blogg Understanding Durability &Write Safety in MongoDB.

Exempel:

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

Ovanstående inläggs skrivproblem kan läsas på följande sätt:  bekräfta denna skrivning när "minst 2 medlemmar av replikuppsättningen har skrivit det till sina journaler inom 5000 msek eller returnerar ett fel '. Ett skrivbekymmersvärde för alternativet var majoritet, vilket betyder "rbegäran bekräftelse på att skrivoperationer har spridits till majoriteten av röstningsnoderna, inklusive de primära. "

#MongoDB Skriv oro - 3 måste-känna varningar Klicka för att tweeta

Vikten av att skriva oro är uppenbar. Ökande värden på w ökar skrivningarnas latens samtidigt som de minskar sannolikheten att gå vilse. Att välja rätt värden för skrivproblem beror på latens- och hållbarhetskraven för skrivningar som utförs.

Med det som bakgrund till vad ett skrivproblem är, låt oss gå vidare till de tre varningarna att komma ihåg när du använder skrivproblem.

VARNING 1: Att ställa in skrivproblem på replikuppsättningar utan wtimeout kan göra att skrivningar blockeras på obestämd tid

Majoritetsdefinitionen (tillämplig MongoDB 3.0 och framåt) ovan anger att bekräftelse begärs från en majoritet av "röstnoderna". Observera att “Om du inte anger wtimeout alternativet och nivån av skrivproblem är ouppnåelig, kommer skrivoperationen att blockeras på obestämd tid. "

Detta kan få oväntade konsekvenser, överväg till exempel en 2+1 replikuppsättning (dvs. en primär, en sekundär och en arbiter). Om din enda läsreplika försvinner kommer alla skrivningar med skrivproblem med alternativet "majoritet" att blockeras på obestämd tid. Detsamma kommer att hända om w-alternativet är satt till 2. Ett annat extremt exempel är i fallet med en 3+2 replikuppsättning (primär, 2 sekundär och 2 arbiters, inte en rekommenderad konfiguration). Alla "majoritets"-skrivningar blockeras även om en enskild datanod inte är tillgänglig eftersom majoritetstalet, i det här fallet, är 3.

Det enklaste sättet att lindra detta problem är att alltid ange ett wtimeout-värde så att frågan kan timeout om skrivproblemet inte kan upprätthållas. Men i händelse av sådana timeout-fel, ångrar MongoDB inte redan lyckade skrivningar som gjorts till några av medlemmarna innan timeout inträffade.

Det finns för närvarande ingen inställning för att säkerställa att en skrivning når de flesta noder som för närvarande är tillgängliga, så var försiktig med att ställa in värdet för skrivproblem w baserat på önskad topologi hållbarhet och tillgänglighet.

VARNING 2: Du kan förlora data även med w:majoritet

Det verkar intuitivt att när en skrivning väl har bekräftats av majoriteten av röstberättigade medlemmar är dess hållbarhet garanterad. Men så är inte fallet! Kom ihåg att när j-alternativet är ospecificerat, kvitteras en skrivning direkt efter att den har skrivits till minnet.

Så, en sådan skrivning kan gå förlorad om ett freak strömavbrott tar bort majoriteten av noderna som skrivningen hade fortplantat sig till (och före syncPeriodSecs, dvs innan den kunde spolas till disk).

För att säkerställa hållbarheten för skrivningar är det bäst att inte stänga av journalföring på din databas och ställa in j-alternativet på sant. I själva verket börjar MongoDB 3.6, --nojournal flaggan har fasats ut för replikuppsättningsmedlemmar som använder WiredTiger-lagringsmotorn.

Med ett w-värde på "majority" och alternativet j ospecificerat på en replikuppsättning, beror det exakta hållbarhetsbeteendet på värdet för replikuppsättningens konfiguration writeConcernMajorityJournalDefault. När den är inställd på sann (och när journalföring är aktiverad), bekräftar den skrivningar efter att de har skrivits till journalerna för en majoritet av röstberättigade medlemmar.

Åt sidan:Även om journalföring är aktiverat kan dina skrivningar fortfarande gå vilse i MMAPv1-lagringsmotorn om ett avbrott inträffar inom commitIntervalMs varaktighet. WiredTiger-lagringsmotorn, å andra sidan, tvingar fram en synkronisering av journalfiler när den tar emot en skrivning med j-alternativet satt till sant. Och även med j inställt på false kan en bekräftad "majoritets"-skrivning till en senaste WiredTiger-baserad distribution bara gå förlorad när majoriteten av datanoderna kraschar samtidigt.

VARNING 3: w:0 medan inställningen j:true inte förbättrar skrivprestandan

Detta är lätt nog att resonera när du väl tänker efter, men lika lätt att glömma. Att ställa in w-alternativet till 0 görs vanligtvis för att skriva till databasen på ett "eld-och-glöm"-sätt - när du har en hel del förtroende för databasinfrastrukturen och bryr dig mer om latens än hållbarheten för varje skrivning. Men om du ställer in alternativet j till sant, kommer ditt w-alternativ att åsidosättas eftersom databasen säkerställer att skrivningen skrivs till journalen på disken innan den returneras.

Om du använder skrivproblem för att garantera framgången för dina skrivoperationer, se till att du kommer ihåg dessa tre avgörande varningar! Vi är här för att hjälpa dig, så kontakta gärna med alla frågor via Twitter eller via e-post.


  1. Benchmarking MongoDB - Driving NoSQL Performance

  2. Redis beteende med flera samtidiga program som gör läs/del på samma hash-nyckel

  3. MongoDB välj antal (distinkt x) på en indexerad kolumn - räkna unika resultat för stora datamängder

  4. MongoDB uppdaterar data i kapslat fält