Проблемът за запис по подразбиране в MongoDB е w:1 от MongoDB 2.2 през 2012 г.
Има три различни настройки, които можете да използвате, за да настроите проблема за запис в текущите версии на MongoDB (версия 3.2.6 и по-нова):
wнастройката :колко възли трябва да потвърдят записа, преди да го обявят за успешен. По подразбиране е 1, което означава, че потвърждението на основния възел е достатъчно.jнастройката :записите трябва ли да се регистрират преди да бъдат потвърдени? По подразбиране зависи отwriteConcernMajorityJournalDefault.- writeConcernMajorityJournalDefault
:ако посочите
w:majorityнастройка за загриженост за писане за вашите записи без настройкаj, какво е подразбиращото сеjстойност? По подразбиране еtrue(записите трябва да се регистрират в по-голямата част от възлите за гласуване, преди да бъдат потвърдени).
Има и wtimeout настройка
за да конфигурирате колко дълго MongoDB трябва да чака, за да бъде удовлетворен проблемът за запис, преди да информира клиента, че записът не е бил потвърден. В противен случай записите, които чакат да бъдат удовлетворени, могат да чакат вечно, вместо да се провалят.
Специалната настройка тук е w:majority . Това означава, че записите трябва да се разпространят до по-голямата част от възлите за гласуване (а също и към техните дневници) в реплика, която трябва да бъде призната. Това вероятно е най-безопасната настройка, като същевременно осигурява добра производителност, защото:
- Това предотвратява връщането на потвърдените записи в случай на неуспехи.
- Регулира пропускателната способност на приложението, така че да не изпраща записи по-бързо от това, което комплектът реплики може да обработи (поради хардуерни ограничения, мрежова ситуация и т.н.).
Както си представяте, възлите за гласуване включват арбитър . По този начин, в набор от реплики с настройка първичен-вторичен-арбитър, w:majority може да се провали в сценарий, при който:
- Един от възлите, носещи данни, е офлайн по някаква причина.
- Наборът реплики все още е онлайн с първичен записваем, тъй като топологията вече е първичен-арбитър-офлайн.
- Пише с
w:1ще успее както обикновено, но тези записвания могат да бъдат отменени (тъй като не са записани в по-голямата част от възлите, носещи данни за гласуване). - Тъй като арбитърът не носи данни,
w:majorityзаписите ще бъдат неуспешни (или чакат безкрайно), тъй като арбитърът се брои като възел за гласуване.
Поради тази причина използването на арбитър не се препоръчва, ако планирате да използвате w:majority във вашето приложение.
Моля, имайте предвид, че използването на арбитър в набор от реплики от 3 възела, който формира шард в разделен клъстер, също не се препоръчва, тъй като преместванията на парчета изискват w:majority . Наличието на повреда на носещ данни възел в един шард ще бъде пагубно за операциите за мигриране на парчета.
