Community

MarkLogic 10 and Data Hub 5.0

Latest MarkLogic releases provide a smarter, simpler, and more secure way to integrate data.

Read Blog →

Company

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up →

 
Knowledgebase: Administration
How does "point-in-time" recovery work with Journal Archiving?
21 April 2020 11:20 AM

Introduction

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

Process overview

In order to successfully perform a point-in-time recovery, the following steps need to take place:

  • A backup of a database at a given timestamp
  • Performing an insert of a number of new documents after that timestamp
  • A restore back to the previous timestamp

Adding Content

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

Check Timestamps

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

Delete Everything

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:

  • Run the delete script again to clear the database
  • Create the backup (ensure that you set "Archive Journals" to true when doing this)
  • Set the merge timestamp on the database to a value greater than zero, for example: 1 (if you don't do this, when you attempt to restore, you will see an error message 'Error: XDMP-MERGETIMESTAMPMISSING: Merge timestamp must be set to non-zero value when restoring with journal archiving and restore-to-time is zero)'
  • Run the restore - remember to add the full path in the 'restore from directory' so the restore routine can find the BackupTag. Please ensure 'Use journal archive' is enabled and leave the 'Restore to time' blank so a full restore is performed
  • Run the xdmp:forest-rollback code as before and confirm the documents are all available after doing so
  • Set the merge timestamp back to zero
(8 vote(s))
Helpful
Not helpful

Comments (0)