Kurze Antwort:nicht.
Lange Antwort:Das automatische Failover in MongoDB funktioniert so, dass ein Replikatsatz eine qualifizierte Mehrheit benötigt, um erfolgreich einen neuen Primärserver zu wählen. Verspätete Mitglieder haben Stimmen bei Wahlen. Also wenn entweder Ihrer Knoten ausfällt, stellt der Replikatsatz fest, dass er nicht über diese Mehrheit verfügt, und der aktuelle primäre Knoten tritt zurück, selbst wenn er nicht ausgefallen ist. Was Sie also im Wesentlichen tun, ist verdoppeln die Wahrscheinlichkeit, dass Ihr Replikatsatz fehlschlägt. Ein Arbiter ist ein sehr billiger Prozess in Bezug auf RAM-Nutzung, CPU und sogar Festplattenspeicher, wenn er mit --smallfiles --no-journal --noprealloc ausgeführt wird oder die entsprechenden Optionen, die in der Konfigurationsdatei festgelegt sind. Beachten Sie, dass die erwähnten Optionen sicher zu verwenden sind, da ein Arbiter im Wesentlichen nur die Herzschläge der datentragenden Knoten prüft. Sie könnten den Arbiter beispielsweise auf dem Anwendungsserver platzieren.
Haftungsausschluss:Von der Verwendung des folgenden Verfahrens wird dringend abgeraten. Fahren Sie auf eigene Gefahr fort.
Sie könnten die Stimmen des verzögerten Servers auf 0 setzen. Auf diese Weise fordert der unverzögerte Knoten eine Wahl, falls das verzögerte Mitglied ausfällt, zu dem Schluss kommt, dass er der einzige online Knoten des Replikatsatzes ist und dass es die Mehrheit der Stimmen (1/1) hat und wie erwartet weiterarbeiten wird. Diese Vorgehensweise erfordert einige Aufmerksamkeit, da Sie wieder eine gerade Anzahl von Stimmen haben, falls Sie später ein Mitglied zum Replica-Set hinzufügen und es erforderlich machen, das Replica-Set neu zu konfigurieren. Es hat auch schwerwiegende Auswirkungen auf Probleme mit der Netzwerkfragmentierung. Nochmals:Verwendung auf eigene Gefahr
