|
|
xdmp:database-backup(
|
|
$forestIDs as unsignedLong*,
|
|
$pathname as xs:string
|
| ) as xs:unsignedLong |
|
|
|
Summary:
Starts an asynchronous backup of the specified list of forests to the
backup data directory. Returns a job ID that uniquely identifies the
backup task.
|
Parameters:
|
$forestIDs
:
A sequence of forest IDs.
|
|
$pathname
:
A backup data directory pathname. The directory must exist and be
writable by the operating system user under which MarkLogic Server
is running. The directory cannot be the MarkLogic Server install
directory or the MarkLogic Server data directory.
|
|
Required Privilege:
http://marklogic.com/xdmp/privileges/xdmp-database-backup
|
Usage Notes:
You cannot restore to a read-only forest.
Reindexing will stop while a backup or restore is in progress.
The backup directory must exist on each host that has a forest
specified in the database backup call (that is, the d-nodes in which the
forests being backed up are hosted).
|
Example:
xdmp:database-backup((11183608861595735720,898513504988507762),
"/backups/Data")
=> 33030877979801813489
|
Example:
xdmp:database-backup(xdmp:database-forests(xdmp:database("Documents")),
"/backups/Data")
=> 437302857479804813287
|
|
|
|
xdmp:forest-rollback(
|
|
$forestIDs as unsignedLong*,
|
|
$timestamp as 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 Privilege:
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 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)
|
|
|