89 lines
3.6 KiB
Plaintext
89 lines
3.6 KiB
Plaintext
[[indices-forcemerge]]
|
|
=== Force Merge
|
|
|
|
The force merge API allows you to force a <<index-modules-merge,merge>> on the
|
|
shards of one or more indices. Merging reduces the number of segments in each
|
|
shard by merging some of them together, and also frees up the space used by
|
|
deleted documents. Merging normally happens automatically, but sometimes it is
|
|
useful to trigger a merge manually.
|
|
|
|
WARNING: **Force merge should only be called against an index after you have
|
|
finished writing to it.** Force merge can cause very large (>5GB) segments to
|
|
be produced, and if you continue to write to such an index then the automatic
|
|
merge policy will never consider these segments for future merges until they
|
|
mostly consist of deleted documents. This can cause very large segments to
|
|
remain in the index which can result in increased disk usage and worse search
|
|
performance.
|
|
|
|
Calls 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.
|
|
|
|
[source,console]
|
|
--------------------------------------------------
|
|
POST /twitter/_forcemerge
|
|
--------------------------------------------------
|
|
// TEST[setup:twitter]
|
|
|
|
Force-merging can be useful with time-based indices and when using
|
|
<<indices-rollover-index,rollover>>. In these cases each index only receives
|
|
indexing traffic for a certain period of time, and once an index will receive
|
|
no more writes its shards can be force-merged down to a single segment:
|
|
|
|
[source,console]
|
|
--------------------------------------------------
|
|
POST /logs-000001/_forcemerge?max_num_segments=1
|
|
--------------------------------------------------
|
|
// TEST[setup:twitter]
|
|
// TEST[s/logs-000001/twitter/]
|
|
|
|
This can be a good idea because single-segment shards can sometimes use simpler
|
|
and more efficient data structures to perform searches.
|
|
|
|
[float]
|
|
[[forcemerge-parameters]]
|
|
==== Request Parameters
|
|
|
|
The force merge API accepts the following request parameters:
|
|
|
|
[horizontal]
|
|
`max_num_segments`:: The number of segments to merge to. To fully
|
|
merge the index, set it to `1`. Defaults to simply checking if a
|
|
merge needs to execute, and if so, executes it.
|
|
|
|
`only_expunge_deletes`:: 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 `false`. Note that this won't override the
|
|
`index.merge.policy.expunge_deletes_allowed` threshold.
|
|
|
|
`flush`:: Should a flush be performed after the forced merge. Defaults to
|
|
`true`.
|
|
|
|
[source,console]
|
|
--------------------------------------------------
|
|
POST /kimchy/_forcemerge?only_expunge_deletes=false&max_num_segments=100&flush=true
|
|
--------------------------------------------------
|
|
// TEST[s/^/PUT kimchy\n/]
|
|
|
|
[float]
|
|
[[forcemerge-multi-index]]
|
|
==== Multi Index
|
|
|
|
The 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.
|
|
|
|
|
|
[source,console]
|
|
--------------------------------------------------
|
|
POST /kimchy,elasticsearch/_forcemerge
|
|
|
|
POST /_forcemerge
|
|
--------------------------------------------------
|
|
// TEST[s/^/PUT kimchy\nPUT elasticsearch\n/]
|