Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force Merge: clarify execution and storage requirements #33882

Merged
merged 4 commits into from
Oct 23, 2018
Merged

Force Merge: clarify execution and storage requirements #33882

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d290284
Multi index operations are executed synchronously.
frederikbosch Sep 20, 2018
026365d
Update remark on sync/async merging multiple indices
frederikbosch Oct 5, 2018
aaec237
clarified sentence
javanna Oct 23, 2018
78d8332
Merge branch 'master' into patch-1
javanna Oct 23, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/reference/indices/forcemerge.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,8 @@ POST /kimchy/_forcemerge?only_expunge_deletes=false&max_num_segments=100&flush=t
=== Multi Index

The force merge API can be applied to more than one index with a single call, or
even on `_all` the indices.
even on `_all` the indices. Multi index operations are executed async for all nodes,
but one shard at a time per node. This will cause storage to increase per node.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we remove the async part please, which is generally how Elasticsearch works? Also, I think it is valuable to add info about storage requirements, but if we do so we should be more specific. The worst case is when force_merge is executed with max_num_segments set to 1, in which case we should clarify that the storage temporarily goes up to potentially 100% of the size of the shard being merged. That means that running each shard per node sequentially is good when looking at storage requirements ;)


[source,js]
--------------------------------------------------
Expand Down