Problem dotyczący zapisu MongoDB:3 zastrzeżenia, które musisz znać

„Zastrzeżenie dotyczące zapisu” w MongoDB opisuje poziom potwierdzenia zapisu, którego możesz się po nim spodziewać. Jest to dość ważne ustawienie, o którym należy pamiętać podczas operacji zapisu, a jego zachowanie jest przydatne do zrozumienia, zwłaszcza w rozproszonych wdrożeniach MongoDB (tj. zestawach replik i klastrach podzielonych na fragmenty). W tym poście omówimy 3 problemy związane z korzystaniem z MongoDB.

Problem związany z zapisem MongoDB

Dokumentacja MongoDB definiuje problem związany z zapisem jako „poziom potwierdzenia żądanego od MongoDB dla operacji zapisu do samodzielnego mongod lub do zestawów replik lub do klastrów podzielonych na fragmenty. „

Mówiąc prosto, problem z zapisem jest wskaźnikiem „trwałości” przekazywanej wraz z operacjami zapisu do MongoDB. Aby wyjaśnić, spójrzmy na składnię:

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

* Szczegółową składnię można znaleźć w dokumentacji Write Concern Specification.

* Dowiedz się więcej o różnych „tagach”, których można używać w przypadku typowych wartości związanych z zapisem, w naszym blogu Zrozumienie trwałości i bezpieczeństwa zapisu w MongoDB.

Przykład:

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

Powyższy problem dotyczący zapisu wstawki można odczytać w następujący sposób: potwierdź ten zapis, gdy „co najmniej 2 członków zestawu replik napisało go w swoich dziennikach w ciągu 5000 ms lub zwróciło błąd „. Wartością problemu z zapisem dla opcji była większość, co oznaczało „rpotwierdzenie, że operacje zapisu zostały rozesłane do większości węzłów głosujących, w tym do głównego. „

Ważne jest zainteresowanie zapisem. Zwiększanie wartości w zwiększa opóźnienie zapisów, jednocześnie zmniejszając prawdopodobieństwo ich utraty. Wybór poprawnych wartości dla problemów związanych z zapisem zależy od wymagań dotyczących opóźnień i trwałości wykonywanych zapisów.

Mając to jako tło problemu związanego z zapisem, przejdźmy do trzech zastrzeżeń, o których należy pamiętać podczas korzystania z problemu związanego z zapisem.

OSTRZEŻENIE 1: Ustawienie problemu zapisu w zestawach replik bez limitu czasu może spowodować, że zapisy będą blokować się w nieskończoność

Definicja większości (dotycząca MongoDB 3.0 i nowszych) powyżej stwierdza, że ​​potwierdzenie jest wymagane od większości „węzłów głosujących”. Zauważ, że „Jeśli nie określisz wtimeout i poziom zainteresowania zapisem jest nieosiągalny, operacja zapisu zostanie zablokowana na czas nieokreślony. „

Może to mieć nieoczekiwane konsekwencje, na przykład rozważ zestaw replik 2+1 (tj. podstawowy, drugorzędny i arbitra). Jeśli twoja jedyna replika do odczytu ulegnie awarii, wszystkie zapisy z problemem zapisu z opcją „większości” będą blokowane na czas nieokreślony. To samo stanie się, jeśli opcja w zostanie ustawiona na 2. Innym ekstremalnym przykładem jest przypadek zestawu replik 3+2 (pierwotna, 2 drugorzędne i 2 arbitrów, konfiguracja niezalecana). Wszystkie zapisy „większościowe” zostaną zablokowane, nawet jeśli pojedynczy węzeł danych jest niedostępny, ponieważ liczba większościowa, w tym przypadku, to 3.

Najprostszym sposobem na złagodzenie tego problemu jest zawsze określanie wartości wtimeout, aby zapytanie mogło wygasnąć, jeśli nie można wyegzekwować problemu z zapisem. Jednak w przypadku takich błędów przekroczenia limitu czasu, MongoDB nie cofa już udanych zapisów dokonanych do niektórych członków przed upływem limitu czasu.

Obecnie nie ma również ustawienia zapewniającego, że zapis dotrze do większości węzłów, które są aktualnie osiągalne, więc należy uważać na ustawienie wartości problemu zapisu w na podstawie pożądanej topologii trwałość i dostępność.

OSTRZEŻENIE 2: Możesz utracić dane nawet przy:większości

Wydaje się intuicyjne, że gdy tekst zostanie uznany przez większość głosujących członków, jego trwałość jest gwarantowana. Tak jednak nie jest! Pamiętaj, że gdy opcja j jest nieokreślona, ​​zapis jest potwierdzany zaraz po zapisaniu do pamięci.

Tak więc taki zapis może zostać utracony, jeśli dziwna przerwa w dostawie prądu usunie większość węzłów, do których propaguje się zapis (i przed syncPeriodSecs, tj. zanim można go było opróżnić do dysku).

Aby zapewnić trwałość zapisów, najlepiej nie wyłączać księgowania w bazie danych i ustawić opcję j na true. W rzeczywistości, począwszy od MongoDB 3.6, --nojournal flaga została uznana za przestarzałą dla członków zestawu replik korzystających z silnika pamięci masowej WiredTiger.

W przypadku wartości w „większości” i nieokreślonej opcji j w zestawie replik, dokładne zachowanie trwałości zależy od wartości writeConcernMajorityJournalDefault konfiguracji zestawu replik. Po ustawieniu na true (i gdy włączone jest rejestrowanie), potwierdza zapisy po ich zapisaniu w dziennikach większości członków głosujących.

Poza tym:nawet przy włączonym księgowaniu zapisy w aparacie pamięci masowej MMAPv1 mogą się nadal gubić, jeśli w czasie trwania CommitIntervalMs wystąpi awaria. Z drugiej strony mechanizm przechowywania WiredTiger wymusza synchronizację plików dziennika, gdy otrzymuje zapis z opcją j ustawioną na true. I nawet jeśli j jest ustawione na false, potwierdzony „większość” zapisu do najnowszego wdrożenia opartego na WiredTiger może zostać utracony tylko wtedy, gdy większość węzłów danych ulegnie awarii jednocześnie.

OSTRZEŻENIE 3: w:0 przy ustawieniu j:true nie poprawia wydajności zapisu

Wystarczająco łatwo o tym pomyśleć, gdy się nad tym zastanowisz, ale równie łatwo o tym zapomnieć. Ustawienie opcji w na 0 jest zwykle wykonywane w celu zapisania do bazy danych w sposób „uruchom i zapomnij” – kiedy masz dość zaufania do infrastruktury bazy danych i bardziej zależy ci na opóźnieniach niż na trwałości każdego zapisu. Jeśli jednak ustawisz opcję j na true, Twoja opcja w zostanie skutecznie nadpisana, ponieważ baza danych zapewni, że zapis zostanie zapisany w dzienniku na dysku przed powrotem.

Jeśli używasz wątpliwości związanych z zapisem, aby zagwarantować powodzenie operacji zapisu, pamiętaj o tych trzech kluczowych zastrzeżeniach! Jesteśmy tutaj, aby pomóc, więc nie krępuj się odpowiadać na wszelkie pytania za pośrednictwem Twittera lub poczty e-mail.