![\"images\"](\"\/blog\/wp-ttn-blog\/uploads\/2016\/04\/images.png\")
<\/p>\n<\/p>\n
While working with databases sometimes there is a\u00a0need to have data till\u00a0a specific time or date across all the secondaries or database peers which is useful for testing a particular functionality. Also, in the event of outage, few folks would like to restore it to a specific weekend or month end just to have uniformity across all the dependent applications.<\/p>\n
Here I am\u00a0going to discuss how it can be achieved in MongoDB<\/a>. I will be using MongoDB\u2019s native tools – mongodump & mongorestore. Although these tools are heavily used to take database\/table dumps of mongo data, these can also be used to have Oplog backup. Before proceeding, you must have idea of Oplog. <\/span><\/p>\n Oplog is like a normal collection (or table) in MongoDB which keeps all the operations that are received by MongoDB on its port. These operations can be updates, inserts, deletes etc. That means a working or executing copy of all the transactions that are stored in the normal collections will also be there in Oplog. However, this cannot be treated as a backup. You must keep your backup copies as well since Oplog is a capped collection,\u00a0which means that it will keep overwriting the oldest data as new data comes in, once its capacity is full. So, choose Oplog size accordingly. <\/span><\/p>\n To have mongo restored to point in time, you must take its backup accordingly. This assumes you are already taking mongo data backups regularly. Just in addition to that, take Oplog dump as well:<\/span><\/p>\n Here is what you need to take backup of – <\/span>oplog.rs<\/b> collection: <\/span><\/p>\n Take the backup using mongodump:<\/span><\/p>\n From above command, \u00a0<\/span>local<\/b> is the database and <\/span>oplog.rs<\/b> is the collection name. oplogBack_5April2016 is the non-existent directory where you will take backup. <\/span>oplog.rs.bson<\/b> is the required dump collected after running this command and which will be used to have point-in-time restored data. <\/span><\/p>\n To restore to point in time, you must have your \u2018time\u2019 handy. What that means is you must know the date and time up to which you want to actually restore. That is calculated on the basis of <\/span>epoch<\/span><\/a> value. Oplog keep all the transactions on the basis of this epoch value available as <\/span>timestamp<\/b>. <\/span><\/p>\n Now suppose you want to restore up to a date, say 31st March 2016 23:59:00. Its epoch value will be calculated as <\/span>1459468740<\/i><\/b>. Having said that, it is not necessary Oplog will have a record created exact on the same time, it might create a record earlier or later to this time. And obviously that will happen most of the time. In that scenario, you must find an epoch value just less than the required epoch time and you will restore up to that timestamp. Your goal is to find <\/span>\u201c”ts”:{“timestamp”:{“t”:x,”i”:y}}\u201d<\/b> entry and note its values from Oplogs. X is the epoch value we are interested in and Y is an incrementing ordinal for operations within a given second. In case you find more than 1 value of Y for the same value of X, you should use the largest Y value.<\/span><\/p>\n In my case, I created and used this <\/span>script<\/span><\/a> to get an epoch just less than my desired point-in-time epoch value from Oplogs. To be able to use this script you must have your Oplog dump in human readable format. <\/span>bsondump<\/span><\/a> is such utility to convert your bson dump to json values. <\/span><\/p>\n Say or For example, I have got \u201cts\u201d : timestamp(1459464310, 1) <\/b>& <\/span>\u201cts\u201d : timestamp(1459464310, 2)<\/b> as epoch just less than my desired timestamp value. This corresponds to <\/span>31 Mar 2016 22:45:10<\/span><\/i> and this is the last record my Oplog had just before 31st March 23:59:00. The ordinal value I choose will be 2. <\/span><\/p>\n Once you are ready with the Oplog dump and the correct epoch and ordinal values, use following procedure for restoration:<\/p>\n Step1<\/b>. Restore the normal data from latest dump just before the point-in-time timestamp. Say you do weekly backup and so you had backup only till 27th March 2016 (<\/span>Sunday<\/span><\/i>). So, restore the data on new node up to 27th March 2016. It will be done using your normal restoration procedure.<\/span><\/p>\n Step2<\/b>: Rename your dump with <\/span>oplog.bson<\/b> as mongorestore will look for oplog.bson in the specified directory or in the root of dump directory if no directory specified.<\/span><\/p>\n Step3<\/b>. Replay your Oplogs until <\/span>1459464310:2.<\/b><\/p>\n –oplogReplay: <\/b>Replays the oplog after restoring the dump to ensure that\u00a0<\/span>the current state of the database reflects the point-in-time backup.<\/p>\n –oplogLimit: <\/b>Prevents mongorestore from applying oplog entries with\u00a0<\/span>timestamp newer than or equal to <timestamp>.<\/p>\n \u00a0<\/span>oplogRest<\/b>: This is the directory where I have kept my oplog.bson.<\/span><\/p>\n Just note that restoring Oplogs is an idempotent activity and it will do\u00a0no harm if you run this multiple times. This is the time you can verify if you have restored correctly upto your desired timestamp. That should be all.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" While working with databases sometimes there is a\u00a0need to have data till\u00a0a specific time or date across all the secondaries or database peers which is useful for testing a particular functionality. Also, in the event of outage, few folks would like to restore it to a specific weekend or month end just to have uniformity […]<\/p>\n","protected":false},"author":181,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":36},"categories":[1],"tags":[1900,3224,3223,3226,3225,3220],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/33468"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/181"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=33468"}],"version-history":[{"count":0,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/33468\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=33468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=33468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=33468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"oplog_collection\"](\"\/blog\/wp-ttn-blog\/uploads\/2016\/04\/oplog_collection.png\")
<\/strong><\/strong><\/p>\n![\"mongodump\"](\"\/blog\/wp-ttn-blog\/uploads\/2016\/04\/mongodump.png\")
<\/strong><\/strong><\/p>\n![\"bsondump\"](\"\/blog\/wp-ttn-blog\/uploads\/2016\/04\/bsondump.png\")
<\/strong><\/strong><\/p>\n![\"rename\"](\"\/blog\/wp-ttn-blog\/uploads\/2016\/04\/rename.png\")
<\/strong><\/strong><\/p>\n![\"mongorestore\"](\"\/blog\/wp-ttn-blog\/uploads\/2016\/04\/mongorestore.png\")
<\/strong><\/strong><\/p>\n