Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-3679

Point in Time Recovery

    • Type: Icon: New Feature New Feature
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None

      We would like point in time recovery for MongoDB. For instance, each time you recycle a journal, spool it to file first according to a parameter for it's destination. Allow for recovery to read from this destination if it exists, and the files are there. A scheme needs to be created to allow for recovery to be brought up to some point and stopped. There are analogs in MySQL, PostgreSQL, Oracle, etc.

      http://dev.mysql.com/doc/refman/5.1/en/point-in-time-recovery.html

      The enterprise use case is, say, a horrible piece of code was pushed to the live site. It deleted data or something, and all the slaves consumed the change. The lagged standby is 8 hours old, the problem is only 1 hour old. It would be a shame to have to logically rollback 7 hours of otherwise OK operations.

      One could potentially manually do this operation today by opening the slave, essentially deleting oplog entries (recreate the oplog with the stuff you want), and then removing slaveDelay, but it's hacky/risky/tricky and could confuse the heck out of the replica set I suspect. Point in time recovery could potentially be based on slaveDelay if one allows for recovering up to a point, then become master. I could envision a series of replica set commands that allow for this. So thats a potentially different approach to get point in time recovery functionality.

            Assignee:
            Unassigned Unassigned
            Reporter:
            kgorman Kenny Gorman
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: