Ich habe mich im Juli für M202: MongoDB Advanced Deployment and Operations eingetragen (nächster Start im September).
Dabei bin ich über ein ganz faszinierendes Problem gestolpert:
- Eine laufende MongoDB
- Es gibt jeden Tag um Mitternacht ein Backup
- Irgendwann in den frühen Morgenstunden hat jemand eine Collection gedropped.
- Aufgabe: Restore des Standes von Mitternacht UND aller Operationen bis zum Zeitpunkt direkt bevor die Collection gelöscht wurde
Was ist also zu tun?
Hole das Oplog aus der laufenden Datenbank
mongodump -d local -c oplog.rs -o oplogD --dbpath /data/backuptest
Suche wo der drop passiert ist
bsondump oplogR/oplog.rs.bson | grep drop
{ "ts" : Timestamp( 1398778745, 1 ), "h" : NumberLong(-4262957146204779874), "v" : 2, "op" : "c", "ns" : "backupDB.$cmd", "o" : { "drop" : "backupColl" } }
Beachte den Timestamp – den brauchen wir später noch
"ts" : Timestamp( 1398778745, 1 )
Restore the Backup:
mongorestore --collection backupColl --db backupDB backupDB/backupColl.bson --dbpath /data/backuptest
Entfernen des Oplogs aus dem Backup, etwas brutal, reicht aber für die Aufgabenstellung
rm /data/backuptest/local.*
Wird das nicht gemacht, kann das Oplog von vorhin nicht eingefügt werden. Der Hintergrund ist, dass wir durch den Restore bereits neuere Einträge im Oplog haben, als von dem Oplog, das wieder eingespielt werden soll. Jetzt kann auf alle Fälle das Oplog eingespielt werden:
mongorestore --oplogReplay --oplogLimit 1398778745:1 oplogR --dbpath /data/backuptest
Datenbank starten
mongod --config mongod.conf --port 30001 --dbpath backuptest --smallfiles --oplogSize 128 &
Fertig!
Es gibt übrigens auch schon eine offizielle Lösung dafür auf Youtube
Schreibe einen Kommentar