Domyślny problem zapisu w MongoDB to w:1 od MongoDB 2.2 w 2012 roku.
Istnieją trzy różne ustawienia, których możesz użyć do ustawienia problemu zapisu w obecnych wersjach MongoDB (wersja 3.2.6 i nowsze):
wustawienie :ile węzłów powinno potwierdzić zapis przed ogłoszeniem sukcesu. Wartość domyślna to 1, co oznacza, że wystarczy potwierdzenie głównego węzła.justawienie :czy zapisy muszą być księgowane, zanim zostaną potwierdzone? Wartość domyślna zależy odwriteConcernMajorityJournalDefault.- writeConcernMajorityJournalDefault
:jeśli określisz
w:majorityustawienie problemu zapisu dla twoich zapisów bez ustawieniaj, jaki jest domniemanyjwartość? Wartość domyślna totrue(zapisy powinny być zapisywane w dzienniku w większości węzłów głosujących, zanim zostaną potwierdzone).
Istnieje również wtimeout ustawienie
aby skonfigurować, jak długo MongoDB powinien czekać na zaspokojenie problemu związanego z zapisem, zanim poinformuje klienta, że zapis nie został potwierdzony. W przeciwnym razie zapisy oczekujące na zaspokojenie problemu związanego z zapisem mogą czekać w nieskończoność zamiast kończyć się niepowodzeniem.
Specjalne ustawienie to w:majority . Oznacza to, że zapisy muszą rozprzestrzeniać się do większości węzłów głosujących (a także do ich dzienników) w zestawie replik do potwierdzenia. Jest to prawdopodobnie najbezpieczniejsze ustawienie, które zapewnia dobrą wydajność, ponieważ:
- Zapobiega wycofywaniu potwierdzonych zapisów w przypadku awarii.
- Reguluje przepustowość aplikacji, aby nie wysyłała zapisów szybciej niż może obsłużyć zestaw replik (ze względu na ograniczenia sprzętowe, sytuację sieciową itp.).
Jak sobie wyobrażałeś, węzły głosujące zawierają arbitra . Tak więc w zestawie replik z konfiguracją główny-drugorzędny-arbiter w:majority może się nie powieść w scenariuszu, w którym:
- Jeden z węzłów przenoszących dane jest z jakiegoś powodu offline.
- Zestaw replik jest nadal w trybie online z zapisywalnym podstawowym, ponieważ topologia jest teraz głównym-arbiterem-offline.
- Zapisuje za pomocą
w:1powiedzie się jak zwykle, ale te zapisy mogą zostać wycofane (ponieważ nie zostały zapisane do większości węzłów głosujących). - Ponieważ arbiter nie ma danych,
w:majorityzapisy zakończą się niepowodzeniem (lub będą czekać w nieskończoność), ponieważ arbiter jest liczony jako węzeł głosujący.
Z tego powodu korzystanie z arbitra nie jest zalecane, jeśli planujesz używać w:majority w Twojej aplikacji.
Należy pamiętać, że używanie arbitra w zestawie replik składających się z 3 węzłów, który tworzy fragment w klastrze podzielonym na fragmenty, również nie jest zalecane, ponieważ ruchy porcji wymagają użycia w:majority . Awaria węzła przenoszącego dane w jednym fragmencie będzie szkodliwa dla operacji migracji porcji.
