Krótka odpowiedź:nie.
Długa odpowiedź:sposób, w jaki działa automatyczne przełączanie awaryjne w MongoDB, polega na tym, że zestaw replik wymaga kwalifikowanej większości, aby pomyślnie wybrać nową bazę. Spóźnieni członkowie mają głosy w wyborach. Więc jeśli albo z twoich węzłów ulega awarii, zestaw replik dowiaduje się, że nie ma tej większości i obecnych podstawowych kroków w dół, nawet jeśli się nie powiódł. Więc to, co zasadniczo robisz, to podwojenie szanse na awarię zestawu replik. Arbiter jest bardzo tanim procesem, jeśli chodzi o użycie pamięci RAM, procesora, a nawet miejsca na dysku, gdy jest uruchamiany z --smallfiles --no-journal --noprealloc lub równoważne opcje ustawione w pliku konfiguracyjnym. Należy zauważyć, że wspomniane opcje są bezpieczne w użyciu, ponieważ arbiter zasadniczo sprawdza tylko tętno węzłów przenoszących dane. Możesz na przykład umieścić arbitra na serwerze aplikacji.
Zastrzeżenie:zdecydowanie odradza się stosowanie poniższej procedury. Kontynuuj na własne ryzyko.
Możesz ustawić głosy opóźnionego serwera na 0. W ten sposób nieopóźniony węzeł wywoła wybory w przypadku awarii opóźnionego członka, dochodzi do wniosku, że jest to jedyny węzeł online zestawu replik i że ma większość głosów (1/1) i będzie nadal działać zgodnie z oczekiwaniami. Ten kierunek działania wymaga pewnej uwagi, ponieważ będziesz mieć ponownie parzystą liczbę głosów w przypadku późniejszego dodania członka do zestawu replik i konieczności ponownego skonfigurowania zestawu replik. Ma to również poważne konsekwencje w kwestii fragmentacji sieci. Ponownie:Używaj na własne ryzyko
