Das Problem (höchstwahrscheinlich)
Die letzte Operation auf der Primärseite ist von „2015-05-15T02:10:56Z“, wohingegen die letzte Operation auf der Sekundärseite von „2015-05-14T11:23:51Z“ stammt, was eine Differenz von ungefähr ist 15 Stunden. Dieses Fenster kann Ihr Replikations-Oplog-Fenster durchaus überschreiten (die Differenz zwischen der Zeit des ersten und des letzten Vorgangseintrags in Ihrem Oplog). Einfach gesagt, es gibt zu viele Operationen auf dem Primärserver, als dass der Sekundärserver aufholen könnte.
Etwas ausführlicher (wenn auch vereinfacht):Während einer anfänglichen Synchronisierung sind die Daten, von denen die sekundäre Synchronisierung erfolgt, die Daten eines bestimmten Zeitpunkts. Wenn die Daten dieses Zeitpunkts synchronisiert sind, stellt die Sekundärseite eine Verbindung zum Oplog her und wendet die Änderungen an, die zwischen diesem Zeitpunkt und jetzt gemäß den Oplog-Einträgen vorgenommen wurden. Dies funktioniert gut, solange das Oplog alle Operationen zwischen dem genannten Zeitpunkt enthält. Aber das Oplog hat eine begrenzte Größe (es ist eine sogenannte begrenzte Sammlung
). Wenn also mehr Operationen auf dem Primärserver ausgeführt werden, als das Oplog während der anfänglichen Synchronisierung aufnehmen kann, werden die ältesten Operationen "ausgeblendet". Der sekundäre erkennt, dass nicht alle Operationen verfügbar sind, die erforderlich sind, um dieselben Daten wie der primäre zu "konstruieren", und weigert sich, die Synchronisierung abzuschließen, und bleibt in RECOVERY Modus.
Die Lösung(en)
Das Problem ist bekannt und kein Fehler, sondern das Ergebnis der inneren Funktionsweise von MongoDB und mehrerer ausfallsicherer Annahmen des Entwicklungsteams. Daher gibt es mehrere Möglichkeiten, mit der Situation umzugehen. Da Sie nur zwei datentragende Knoten haben, sind leider alle mit Ausfallzeiten verbunden.
Option 1:Erhöhen Sie die Oplog-Größe
Dies ist meine bevorzugte Methode, da sie das Problem ein für allemal löst. Es ist jedoch etwas komplizierter als andere Lösungen. Aus einer übergeordneten Perspektive sind dies die Schritte, die Sie unternehmen.
- Fahren Sie die primäre herunter
- Erstellen Sie eine Sicherungskopie des Oplogs mit direktem Zugriff auf die Datendateien
- Starte den
mongodneu im Standalone-Modus - Kopieren Sie das aktuelle Oplog in eine temporäre Sammlung
- Löschen Sie das aktuelle Oplog
- Erstellen Sie das Oplog mit der gewünschten Größe neu
- Kopieren Sie die Oplog-Einträge aus der temporären Sammlung in das glänzende neue Oplog zurück
- Starte
mongodneu als Teil des Nachbausets
Vergessen Sie nicht, den Oplog des sekundären Servers zu erhöhen, bevor Sie die anfängliche Synchronisierung durchführen, da er irgendwann in der Zukunft primär werden kann!
Weitere Informationen finden Sie unter "Change the size of the oplog" in den Tutorials zur Replikatpflege .
Option 2:Beenden Sie die App während der Synchronisierung
Wenn Option 1 nicht praktikabel ist, besteht die einzige echte andere Lösung darin, die Anwendung herunterzufahren, die eine Last auf dem Replikatsatz verursacht, die Synchronisierung neu zu starten und zu warten, bis sie vollständig ist. Rechnen Sie je nach Menge der zu übertragenden Daten mit mehreren Stunden.
Eine persönliche Notiz
Das Problem mit dem oplog-Fenster ist bekannt. Während Replikatsätze und Sharding-Cluster mit MongoDB einfach einzurichten sind, sind einige Kenntnisse und ein wenig Erfahrung erforderlich, um sie ordnungsgemäß zu warten. Führen Sie nichts so Wichtiges wie eine Datenbank mit einem komplexen Setup aus, ohne die Grundlagen zu kennen – falls etwas Schlechtes (tm) passiert, könnte dies durchaus zu einer FUBAR-Situation führen.
