MarkLogic 12 EA 2 Product Documentationxdmp:forest-rollback
xdmp:forest-rollback( $forestIDs as xs:unsignedLong*, $timestamp as xs:unsignedLong ) as empty-sequence()
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).
| Parameters | |
|---|---|
| forestIDs | A sequence of forest IDs. |
| timestamp | The system timestamp to which you want to roll back. |
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:forest-rollback(11183608861595735720, 12345623)
Example
(:
Run this against a different database context then
the my-db database.
:)
xdmp:forest-rollback(
xdmp:database-forests(xdmp:database("my-db")), 12345623)