MarkLogic 9 Product Documentation

xdmp.forestRollback

xdmp.forestRollback(
   forestIDs as (Number|String)[],
   timestamp as (Number|String)
) as null

Summary

Rolls forests back to a previous point in time, marking any fragment newer than the specified timestamp as deleted. Also, any fragments that were created before the specified timestamp and deleted after will be rolled back (un-deleted).

Required Privileges

http://marklogic.com/xdmp/privileges/xdmp-forest-rollback

Usage Notes

If the timestamp specified is greater than the current system timestamp (that is, greater than the value of xdmp:request-timestamp()), then an exception is thrown.

If the specified timestamp is less than (earlier) then the oldest timestamp in the specified forest(s), then an exception is thrown.

You should not have any updates occurring on a forest while it is being rolled back; the best practice is for the forest to be quiesced during a rollback operation.

If you have failover replication configured for a forest, the replica forest(s) will be rolled back at the same time as the specified forest(s).

If MarkLogic Server restarts during a rollback operation, the rollback will complete when the forest comes back online.

You can only roll back a forest that is in the "Open" state.

The updates-allowed setting must be set to all in order to successfully roll a forest back to a previous timestamp.

As part of the xdmp:forest-rollback operation, the specified forest(s) are restarted.

As a consequence of the forest(s) restarting, if the forest is a failover forest and it is failed over to another host, the system will attempt to mount the forest on the original host (that is, it will un-failover the forest).

If you perform an xdmp:forest-rollback operation on a forest attached to the context database or any of its auxilliary databases (the security, modules, or triggers databases for that database), then the rollback is performed asyncronously in the background, and any exceptions that occur will not be reported back to the program; in this case, if an exception occurs it might be reported to the ErrorLog.txt file. Additionally, because the rollback of forests in the context database (or in its auxilliary databases) is run asyncronously, there might be a small delay between when the rollback is issued and when the forest is restarted, and the rollback state is not reflected until the forest restart is completed. Therefore, it is best practice to call xdmp:forest-rollback against forests not attached to the context database.

After an xdmp:forest-clear operation on a forest, you will no longer be able to roll that forest back (because the forest clear deletes all of the stands in the forest).

The forest rollback operation cannot be undone (except by restoring from backup); that is, after rolling a forest back to a point in time, you cannot roll the forest "forward" to where you started.

Example

xdmp.forestRollback(11183608861595735720, 12345623)

Example

//   Run this against a different database context then
//   the my-db database.

xdmp.forestRollback(
     xdmp.databaseForests(xdmp.database("my-db")), 12345623)