Configuring the Merge Policy
The merge policy determines when automatic merges occur on a database, as well as other administrative functions.
To configure the merge policy, follow these steps:
In the Admin Interface tree menu, click the Databases > db_name link, where db_name is the name of the database in which you want to specify merge policy .
Click Merge Policy in the left hand menu. The Merge Policy Configuration page appears.
The following table describes the settings available on the Merge Policy page:
Database Setting |
Description |
|---|---|
|
Specifies the CPU scheduler priority at which merges should run. The settings are:
Merges always run with normal priority on forests with more than 16 stands. |
|
The maximum size, in megabytes, of a stand that will result from a merge. If a stand grows beyond the specified size, it will not be merged. If two stands would be larger than the specified size if merged, they will not be merged together. If you set this to smaller sizes, large merges (which may require more disk and CPU resources) will be prevented. The default is 48 GB (49152 MB), which is recommended because it provides a good balance between keeping the number of stands low and preventing very large merges from using large amounts of disk space. Set this to 0 to allow any sized stand to merge. Use care when setting this to a non-zero value lower than the default value, as this can prevent merges which are ultimately required for the system to maintain performance levels and to allow optimized updates to the system. |
|
The minimum number of fragments that a stand can contain. Two or more stands with fewer than this number of fragments are automatically merged. |
|
A positive integer indicating the minimum ratio between the number of fragments in a stand and the number of fragments in all of the other smaller stands (that is stands with fewer fragments) in the forest. Stands with a fragment count below this ratio relative to all smaller stands are automatically merged with the smaller stands. For an example, see If You Want to Reduce the Number of "Large" Merges. |
|
The timestamp stored on merged stands. This is used for point-in-time queries, and determines when space occupied by deleted fragments and old versions of fragments may be reclaimed by the database. If a fragment is deleted or updated at a time after the merge timestamp, then the old version of the fragment is retained for use in point-in-time queries. Set this to 0 (the default) to let the system reclaim the maximum amount of disk space during merge activities. A setting of 0 will remove all deleted and updated fragments when a merge occurs. Set this to 1 before loading or updating any content to create a complete archive of the changes to the database over time. Set this to the current timestamp to preserve all versions of content from this point on. Set this to a negative number to specify a window of timestamp values, relative to the last merge, at ten million ticks per second. The timestamp is a number maintained by MarkLogic Server that increments every time a change occurs in any of the databases in a system (including configuration changes from any host in a cluster). To set to the current timestamp, click the Click Get Current Timestamp to return the current merge timestamp. |
|
Specify whether the deleted fragments are retained since the last full or incremental backup. When enabled, |
|
Specify times when merges are disabled. To specify a merge blackout period, click the Create tab and specify when you want the blackout to occur. You can make it a recurring blackout period, or specify a one-time blackout period. Use caution when setting large blackout periods when there are significant updates occurring on the system; merges are a normal part of the self-tuning mechanism of the database, and disabling them completely or for long periods of time can cause performance degradation. |