Kort svar:lad være.
Langt svar:måden automatisk failover fungerer på i MongoDB er, at et replikasæt har brug for et kvalificeret flertal for at kunne vælge en ny primær. Forsinkede medlemmer har stemmer ved valg. Så hvis enten af dine noder fejler, finder replikasættet ud af, at det ikke har dette flertal, og de nuværende primære trin ned, selvom det ikke fejlede. Så hvad du i bund og grund gør er fordobling chancerne for at få dit replikasæt til at mislykkes. En arbiter er en meget billig proces med hensyn til RAM-brug, CPU og endda diskplads, når den køres med --smallfiles --no-journal --noprealloc eller de tilsvarende indstillinger, der er angivet i konfigurationsfilen. Bemærk, at de nævnte muligheder er sikre at bruge, da en dommer stort set kun kontrollerer hjerteslagene for de databærende noder. Du kan f.eks. sætte arbiteren på applikationsserveren.
Ansvarsfraskrivelse:Følgende procedure frarådes på det kraftigste at bruge. Fortsæt på eget ansvar.
Du kan indstille den forsinkede servers stemmer til 0. På denne måde vil den uforsinkede node kalde til et valg, hvis det forsinkede medlem mislykkes, når den konklusion, at det er den eneste node online af replikasættet og at den har flertallet af stemmerne (1/1) og vil fortsætte med at arbejde som forventet. Denne fremgangsmåde kræver noget opmærksomhed, da du vil have et lige antal stemmer igen, hvis du tilføjer et medlem til replikasættet senere og gør det nødvendigt at omkonfigurere replikasættet. Det har også alvorlige konsekvenser med netværksfragmenteringsproblemer. Igen:Brug på egen risiko