But this time, no limit argument would be required. You need to copy oplog to an uncapped collection and delete the bad write operations.Īfter you’ve removed all bad operations you can continue the restoration process from a dump of the modified oplog. Here, you need to remember that Oplog is a collection too, and in addition to be queried on, it can also be modified. It’s likely that the good and bad writes happened around the same time. The previous method helps when the good and bad operations are clearly separated by time. This is why you need not give mongorestore a start time. it can be applied multiple times without duplicating data. The value of oplogLimit paramter is the ts property of the faulty query you noted earier. Mongorestore -oplogReplay -oplogLimit 1528225054:1 oplogR You want to restore the data prior to the faulty write operation. Now you have a dump of the oplog in oplogR/oplog.bson. Mv oplogD//oplog.rs.bson oplogR/oplog.bson Take a dump of oplogīefore you can restore your your from oplog, you need to dump it to a file. Then click on 'Create' to set up a new connection.
Like before, launch Robo 3T and open the ‘Manage Connections’ window. Let’s say you found the query and it looked like: 1 Setup a New Replica Set Connection on Robo 3T. So, you can query it to narrow down your results like this: mongodb shell 1 Oplog is a special collection, but still a collection. Now you need to browse the contents of the Oplog and look for the query which corrupted the data in the first place. Make sure the oplog has operations from or before the time the backup was taken, otherwise the restore may not work. Restore whatever latest backup you have before the the data was corrupted. The oplog is a special capped collection that keeps a rolling record of all operations that modify the data stored in your databases. If you never heard of it, go read the docs as I’ll skip to the restoring part. If you’re using a MongoDB replica set, you can use MongoDB Oplog to undo almost any type of recent data loss. This blog is a means to note my learnings from that incident for my future self and others. A query gone wrong had erased valuable data from a MongoDB collection and it needed to be restored. Recently I found myself trying to restore corrupted data to it’s original form.
0 kommentar(er)
