NOTE: You are looking at documentation for an older release. For the latest information, see the current release documentation.
Blocks during a force merge
editBlocks during a force merge
editCalls to this API block until the merge is complete. If the client connection is lost before completion then the force merge process will continue in the background. Any new requests to force merge the same indices will also block until the ongoing force merge is complete.
Force merge should only be called against read-only indices. Running force merge against a read-write index can cause very large segments to be produced (>5Gb per segment), and the merge policy will never consider it for merging again until it mostly consists of deleted docs. This can cause very large segments to remain in the shards.
POST /twitter/_forcemerge
Request Parameters
editThe force merge API accepts the following request parameters:
|
|
The number of segments to merge to. To fully
merge the index, set it to |
|
|
Should the merge process only expunge segments with
deletes in it. In Lucene, a document is not deleted from a segment, just marked
as deleted. During a merge process of segments, a new segment is created that
does not have those deletes. This flag allows to only merge segments that have
deletes. Defaults to |
|
|
Should a flush be performed after the forced merge. Defaults to
|
POST /kimchy/_forcemerge?only_expunge_deletes=false&max_num_segments=100&flush=true
Multi Index
editThe force merge API can be applied to more than one index with a single call, or
even on _all the indices. Multi index operations are executed one shard at a
time per node. Force merge makes the storage for the shard being merged
temporarily increase, up to double its size in case max_num_segments is set
to 1, as all segments need to be rewritten into a new one.
POST /kimchy,elasticsearch/_forcemerge POST /_forcemerge