Restoring Databases with Journal Archiving
After you restore a database with Journal Archiving enabled, each forest will likely have committed its last transaction at different timestamps.
For example, the illustration below shows four forests and their committed transactions. Updates for each transaction are identified by the convention ‘T#-u#’ and commits are identified by a ‘C’. Each forest completed its last commit at a different point in time when the restore is finished. In this example, we are restoring from timestamp 0 to 6, Forest A has only committed transactions up to timestamp 3 while Forest B has committed transactions up to timestamp 6. This means that, in order to return the database to a transactionally consistent state, all forests must be rolled back to timestamp 3 or earlier.
Your options for recovering your data and returning the database to a transactionally consistent state are as follows:
Restore as much data as possible. Follow the procedure described in Restoring to the Safe Timestamp.
Restore data at a specific timestamp. Follow the procedure described in Restoring to a Specific Timestamp.
Restore data at a specific timestamp based on the state of some sample documents. Follow the procedure described in Restoring Based on Sample Documents.
The following sections describe how to use the XQuery API to restore the database. You can also use the Admin Interface to accomplish some of the tasks.
Note
If you are using XA distributed transaction processing, a restore to a point in time may revive some XA transactions that were prepared before the target restore time, and committed/aborted after that time. For details on how to identify XA transactions, see Heuristically Completing a MarkLogic Server Transaction in Developing with XCC.
You cannot roll back through a database clear operation, so you should check the server logs for points in time that any clear operations occurred.