How does "point-in-time" recovery work with Journal Archiving?
21 April 2020 11:20 AM
With the release of MarkLogic 5, a new feature - "Journal Archiving" - was added to the product. This feature allows for point-in-time recoveries to be made to a given database (forest) at any time; essentially, this option allows the restore of changes to all forests in a given database (using a call to a new function - xdmp:forest-rollback() at a particular moment in time. This article will provide a quick "getting started" demo to show the feature in action.
For more information, documentation is available online
In order to successfully perform a point-in-time recovery, the following steps need to take place:
We're using xdmp:eval to insert each document as part of a separate (isolated) transaction:
Important - for this demonstration, we're going to rely on properties fragments to keep track of the last modified date, please ensure it is enabled when you create your test database for this exercise
To get an order-wise list of the documents in the database (note: ensure 'maintain last modified' is set to 'true' so properties fragments are generated):
First point-in-time: 10 documents now in the database
Running the code above against the database should yield something like this:
Doc: /test/1.xml was inserted at: 2013-02-28T17:54:57Z Doc: /test/2.xml was inserted at: 2013-02-28T17:54:58Z Doc: /test/3.xml was inserted at: 2013-02-28T17:54:59Z Doc: /test/4.xml was inserted at: 2013-02-28T17:55:00Z Doc: /test/5.xml was inserted at: 2013-02-28T17:55:01Z Doc: /test/6.xml was inserted at: 2013-02-28T17:55:02Z Doc: /test/7.xml was inserted at: 2013-02-28T17:55:03Z Doc: /test/8.xml was inserted at: 2013-02-28T17:55:04Z Doc: /test/9.xml was inserted at: 2013-02-28T17:55:05Z Doc: /test/10.xml was inserted at: 2013-02-28T17:55:06Z
In this scenario, a test script was inadvertently run on the production server resulting in a loss of data:
Rollback (with xdmp:forest-rollback)
We can use the following code to rollback to a safe timestamp - note that in the example below, we're rolling back the forest to a point just after the 10th document was inserted into the database 2013-02-28T17:55:07Z - but before the "delete-all" script was executed:
Following the same process using Backup and Restore
We're going to repeat the same process, only this time, we will backup after the crisis took place (in this case backing up an empty database). We will then use xdmp:forest-rollback to get the newly-restored forests to a safe timestamp.
The steps are as follows: