Kort antwoord:niet doen.
Lang antwoord:de manier waarop automatische failover in MongoDB werkt, is dat een replicaset een gekwalificeerde meerderheid nodig heeft om met succes een nieuwe primaire te kiezen. Vertraagde leden hebben wel stemmen bij verkiezingen. Dus als ofwel van uw nodes mislukt, komt de replicaset erachter dat deze deze meerderheid niet heeft en de huidige primaire stappen naar beneden, zelfs als deze niet is mislukt. Dus wat je in wezen doet is verdubbelen de kans dat uw replicaset mislukt. Een arbiter is een erg goedkoop proces, in termen van RAM-gebruik, CPU en zelfs schijfruimte wanneer uitgevoerd met --smallfiles --no-journal --noprealloc of de equivalente opties die zijn ingesteld in het configuratiebestand. Merk op dat de genoemde opties veilig te gebruiken zijn, aangezien een arbiter in wezen alleen de hartslagen van de gegevensdragende knooppunten controleert. Je zou de arbiter bijvoorbeeld op de applicatieserver kunnen zetten.
Disclaimer:de volgende procedure wordt sterk afgeraden. Ga verder op eigen risico.
Je zou de stemmen van de vertraagde server op 0 kunnen zetten. Op deze manier zal de onvertraagde node een verkiezing vragen in het geval dat het vertraagde lid faalt, tot de conclusie komt dat het de enige node online is van de replicaset en dat het de meerderheid van de stemmen heeft (1/1) en zal blijven werken zoals verwacht. Deze handelwijze heeft enige aandacht nodig, aangezien u weer een even aantal stemmen krijgt voor het geval u later een lid toevoegt aan de replicaset en het nodig maakt om de replicaset opnieuw te configureren. Het heeft ook ernstige gevolgen voor problemen met netwerkfragmentatie. Nogmaals:Gebruik op eigen risico