Risposta breve:non farlo.
Risposta lunga:il modo in cui funziona il failover automatico in MongoDB è che un set di repliche necessita di una maggioranza qualificata per eleggere con successo un nuovo primario. I membri ritardati hanno voti alle elezioni. Quindi se uno dei due dei tuoi nodi non riesce, il set di repliche scopre che non ha questa maggioranza e l'attuale primaria scende anche se non ha fallito. Quindi quello che essenzialmente fai è raddoppiare le possibilità di far fallire il tuo set di repliche. Un arbitro è un processo molto economico, in termini di utilizzo della RAM, CPU e persino spazio su disco quando viene eseguito con --smallfiles --no-journal --noprealloc o le opzioni equivalenti impostate nel file di configurazione. Si noti che le opzioni menzionate sono sicure da usare, poiché un arbitro essenzialmente controlla solo i battiti cardiaci dei nodi portanti dati. Ad esempio, potresti mettere l'arbitro sul server delle applicazioni.
Disclaimer:si sconsiglia vivamente di utilizzare la seguente procedura. Procedi a tuo rischio.
Puoi impostare i voti del server ritardato a 0. In questo modo il nodo non ritardato chiamerà un'elezione nel caso in cui il membro ritardato fallisca, giunge alla conclusione che è l'unico nodo online del set di repliche e che ha la maggioranza dei voti (1/1) e continuerà a funzionare come previsto. Questa linea di condotta richiede una certa attenzione, poiché avrai di nuovo un numero pari di voti nel caso in cui aggiungi un membro al set di repliche in un secondo momento e rendi necessario riconfigurare il set di repliche. Ha anche serie implicazioni con problemi di frammentazione della rete. Ancora:Utilizza a tuo rischio
