Eines der großen Probleme bei der Beschädigung von Daten durch Anwendungs- oder menschliche Fehler besteht darin, dass der anstößige Schreibvorgang auf dem primären Server sofort auf den sekundären Server repliziert wird.
Dies ist einer der Gründe, warum Benutzer "slaveDelay" nutzen - eine Option, um einen Ihrer sekundären Knoten mit einer festen Zeitverzögerung auszuführen (das hilft Ihnen natürlich nur, wenn Sie den Fehler oder Bug während des kürzeren Zeitraums entdecken die Verzögerung auf dieser Sekundärseite).
Falls Sie keine solche Einrichtung haben, müssen Sie sich auf ein Backup verlassen, um den Zustand der Datensätze wiederherzustellen, die Sie auf ihren Zustand vor dem Fehler zurücksetzen müssen.
Führen Sie alle Vorgänge auf einer separaten, eigenständigen Kopie Ihrer Daten durch – erst nachdem Sie sich vergewissert haben, dass alles ordnungsgemäß neu erstellt wurde, sollten Sie die korrigierten Daten dann in Ihr Produktionssystem verschieben.
Dazu ist eine aktuelle Kopie der Sicherung erforderlich (sagen wir, die Sicherung ist X Stunden alt) und das Oplog auf Ihrem Cluster muss Daten im Wert von mehr als X Stunden enthalten. Ich habe das Oplog des Knotens nicht angegeben, weil (a) jedes Mitglied des Replikatsatzes denselben Inhalt im Oplog hat und (b) es ist Es ist möglich, dass Ihre Oplog-Größe auf verschiedenen Knotenmitgliedern unterschiedlich ist. In diesem Fall möchten Sie die "größte" überprüfen.
Nehmen wir also an, Ihr letztes Backup ist 52 Stunden alt, aber zum Glück haben Sie ein Oplog, das Daten im Wert von 75 Stunden enthält (yay).
Sie haben bereits festgestellt, dass alle Ihre Knoten (Primär- und Sekundärknoten) die „schlechten“ Daten haben, also würden Sie diese letzte Sicherung in einem neuen Mongod wiederherstellen. Hier stellen Sie diese Datensätze wieder her, wie sie vor dem fehlerhaften Update waren – und dann können Sie sie einfach in die aktuelle Primärdatenbank verschieben, von wo aus sie auf alle Sekundärdatenbanken repliziert werden.
Erstellen Sie während der Wiederherstellung Ihres Backups mit diesem Befehl einen Mongodump Ihrer Oplog-Sammlung:
mongodump -d local -c oplog.rs -o oplogD
Verschieben Sie das Oplog in ein eigenes Verzeichnis und benennen Sie es in oplog.bson:
ummkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Jetzt müssen Sie die "anstößige" Operation finden. Sie können das Oplog mithilfe von bsondump in eine für Menschen lesbare Form ausgeben Befehl in der Datei oplogR/oplog.bson (und verwenden Sie dann grep oder what-not, um das "schlechte" Update zu finden). Alternativ können Sie das ursprüngliche Oplog im Replikatsatz über use local abfragen und db.oplog.rs.find() Befehle in der Shell.
Ihr Ziel ist es, diesen Eintrag zu finden und seine ts zu notieren Feld.
Das könnte so aussehen:
"ts" : Timestamp( 1361497305, 2789 )
Beachten Sie, dass der mongorestore Der Befehl hat zwei Optionen, eine namens --oplogReplay und die andere heißt oplogLimit . Sie werden dieses Oplog jetzt auf dem wiederhergestellten eigenständigen Server wiedergeben, ABER Sie werden vor diesem anstößigen Aktualisierungsvorgang aufhören.
Der Befehl wäre (Host und Port sind der Ort, an dem sich Ihr neu wiederhergestelltes Backup befindet):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
Dadurch wird jede Operation aus der Datei oplog.bson im Verzeichnis oplogR wiederhergestellt, die direkt vor dem Eintrag mit dem ts-Wert Timestamp(1361497305, 2789) gestoppt wird.
Denken Sie daran, dass Sie dies auf einer separaten Instanz getan haben, damit Sie die Wiederherstellung überprüfen und die erstellten korrekten Daten wiedergeben können. Sobald Sie dies überprüft haben, können Sie die wiederhergestellten Datensätze an die entsprechende Stelle in der realen Primärinstanz schreiben (und die Weitergabe der Replikation zulassen die korrigierten Datensätze zu den Secondaries).
