Загриженост за записа на MongoDB:3 предупреждения, които трябва да знаете

„Загриженост за писане“ в MongoDB описва нивото на потвърждение на запис, което можете да очаквате от него. Това е доста важна настройка, която трябва да запомните при вашите операции за запис и поведението й е полезно за разбиране, особено при разпределени внедрявания на MongoDB (т.е. набори от реплики и разчленени клъстери). В тази публикация обсъждаме 3 проблеми при използване на опасения за запис на MongoDB.

Притеснение при записване на MongoDB

Документацията на MongoDB дефинира загрижеността за запис като „нивото на потвърждение, поискано от MongoDB за операции на запис към самостоятелен mongod или към набори от реплики или към разчленени клъстери. “

Просто казано, проблемът при запис е индикация за „издръжливост“, предавана заедно с операциите за запис към MongoDB. За да изясним, нека разгледаме синтаксиса:

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

* Можете да намерите подробния синтаксис в документацията на Write Concern Specification.

* Научете повече за различните „тагове“, които можете да използвате за общи стойности на притесненията при писане в нашия блог Разбиране на издръжливостта и безопасността при запис в MongoDB.

Пример:

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

Притеснението за запис на горната вложка може да се прочете по следния начин:  потвърдете това записване, когато „поне 2 члена на набора реплика са го записали в своите дневници в рамките на 5000 ms или върне грешка '. Стойността на притеснението при запис за опцията беше мнозинство, което означава „rиска потвърждение, че операциите по запис са се разпространили до по-голямата част от възлите с гласуване, включително основния. “

Важността на загрижеността за писане е очевидна. Увеличаването на стойностите на w увеличава латентността на записите, като същевременно намалява вероятността им да се изгубят. Изборът на правилните стойности за безпокойство при запис зависи от изискванията за забавяне и издръжливост на извършваните записи.

Имайки това като фон за това какво представлява проблемът при запис, нека преминем към трите предупреждения, които трябва да запомните, когато използвате загриженост за запис.

ПРЕДУПРЕЖДЕНИЕ 1: Задаването на загриженост за запис на набори от реплики без wtimeout може да доведе до блокиране на записите за неопределено време

Дефиницията на мнозинството (приложимо MongoDB 3.0 по-горе) посочва, че се изисква потвърждение от мнозинството от „възлите за гласуване“. Обърнете внимание, че „Ако не посочите wtimeout опция и нивото на загриженост за запис е непостижимо, операцията по запис ще блокира за неопределено време. “

Това може да има неочаквани последици, например, помислете за набор от реплика 2+1 (т.е. първичен, вторичен и арбитър). Ако единствената ви реплика за четене изпадне, тогава всички записи с притеснение за запис w опция „мнозинство“ ще бъдат блокирани за неопределено време. Същото ще се случи, ако опцията w е настроена на 2. Друг краен пример е в случай на набор от реплики 3+2 (основен, 2 вторични и 2 арбитри, не е препоръчителна конфигурация). Всички „мнозинство“ записвания ще бъдат блокирани, дори ако един възел на данни не е наличен, тъй като мажоритарният номер в този случай е 3.

Най-простият начин за облекчаване на този проблем е винаги да посочвате стойност wtimeout, така че заявката да може да изтече, ако проблемът за запис не може да бъде приложен. Въпреки това, в случай на такива грешки при изчакване, MongoDB не отменя вече успешни записи, направени до някои от членовете преди да настъпи изтичането на времето.

Понастоящем също няма настройка, която да гарантира, че записът достига до по-голямата част от възлите, които в момента са достъпни, така че внимавайте да зададете стойността на загрижеността за запис w въз основа на желаната топология издръжливост и наличност.

ПРЕДУПРЕЖДЕНИЕ 2: Може да загубите данни дори с w:мнозинство

Изглежда интуитивно, че след като записът е потвърден от мнозинството от гласуващите членове, неговата издръжливост е гарантирана. Това обаче не е така! Не забравяйте, че когато опцията j не е посочена, записът се потвърждава веднага след като е бил записан в паметта.

Така че, такова записване може да бъде загубено, ако невероятно прекъсване на захранването извади по-голямата част от възлите, до които записът се е разпространил (и преди syncPeriodSecs, т.е. диск).

За да се гарантира трайността на записите, най-добре е да не изключвате воденето на журнал в базата си данни и да зададете опцията j на true. Всъщност, стартирайки MongoDB 3.6, --nojournal флагът е отхвърлен за членове на набора от реплики, използващи механизма за съхранение на WiredTiger.

Със стойност w на „мнозинство“ и опция j, неопределена в набор от реплика, точното поведение на издръжливост зависи от стойността на конфигурацията на набора от реплики writeConcernMajorityJournalDefault. Когато е зададено на true (и когато е активирано воденето на журнал), той потвърждава записите, след като са били записани в дневниците на мнозинството от членовете с право на глас.

Освен:Дори и с включено водене на дневници, записите ви пак може да се загубят в MMAPv1 механизма за съхранение, ако възникне прекъсване в рамките на продължителността на commitIntervalMs. Машината за съхранение на WiredTiger, от друга страна, принуждава синхронизиране на файловете на дневника, когато получи запис с опция j, зададена на true. И дори когато j е зададено на false, потвърдено „мнозинство“ запис в най-ново базирано внедряване на WiredTiger може да бъде загубено само когато повечето от възлите на данни се сринат едновременно.

ПРЕДУПРЕЖДЕНИЕ 3: w:0, докато настройката j:true не подобрява производителността на запис

Това е достатъчно лесно за разсъждение, след като се замислите, но също толкова лесно се забравя. Задаването на опцията w на 0 обикновено се прави, за да се пише в базата данни по начин „изстреляйте и забравите“ – когато имате достатъчно доверие в инфраструктурата на базата данни и се грижите повече за латентността, отколкото за издръжливостта на всяко записване. Въпреки това, ако зададете опцията j на true, вашата опция w ефективно ще бъде отменена, тъй като базата данни ще гарантира, че записът се записва в дневника на диска, преди да се върне.

Ако използвате опасения за запис, за да гарантирате успеха на операциите си по запис, уверете се, че запомняте тези три важни предупреждения! Ние сме тук, за да помогнем, така че не се колебайте да се свържете с всякакви въпроси чрез Twitter или по имейл.