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

[7.7] [DOCS] Explain flood stage watermark #57318

Merged
merged 2 commits into from
May 28, 2020
Merged

[7.7] [DOCS] Explain flood stage watermark #57318

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0cb112a
[7.7] [DOCS] Explain flood stage watermark
May 28, 2020
9027bf3
Adding id to fix cross-linking issue.
May 28, 2020
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
10 changes: 7 additions & 3 deletions docs/reference/index-modules.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -179,9 +179,13 @@ specific index module:

`index.blocks.read_only_allow_delete`::

Similar to `index.blocks.read_only` but also allows deleting the index to
free up resources. The <<disk-allocator,disk-based shard allocator>> may
add and remove this block automatically.
Similar to `index.blocks.read_only`, but also allows deleting the index to
make more resources available. The <<disk-allocator,disk-based shard
allocator>> may add and remove this block automatically.

Deleting documents from an index to release resources - rather than deleting the index itself - can increase the index size over time. When `index.blocks.read_only_allow_delete` is set to `true`, deleting documents is not permitted. However, deleting the index itself releases the read-only index block and makes resources available almost immediately.

IMPORTANT: {es} adds and removes the read-only index block automatically when the disk utilization falls below the high watermark, controlled by <<cluster-routing-flood_stage,cluster.routing.allocation.disk.watermark.flood_stage>>.

`index.blocks.read`::

Expand Down
32 changes: 16 additions & 16 deletions docs/reference/modules/cluster/disk_allocator.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
[[disk-allocator]]
=== Disk-based shard allocation

Elasticsearch considers the available disk space on a node before deciding
{es} considers the available disk space on a node before deciding
whether to allocate new shards to that node or to actively relocate shards away
from that node.

Expand All @@ -16,38 +16,38 @@ file or updated dynamically on a live cluster with the
`cluster.routing.allocation.disk.watermark.low`::

Controls the low watermark for disk usage. It defaults to `85%`, meaning
that Elasticsearch will not allocate shards to nodes that have more than
that {es} will not allocate shards to nodes that have more than
85% disk used. It can also be set to an absolute byte value (like `500mb`)
to prevent Elasticsearch from allocating shards if less than the specified
to prevent {es} from allocating shards if less than the specified
amount of space is available. This setting has no effect on the primary
shards of newly-created indices but will prevent their replicas from being allocated.

`cluster.routing.allocation.disk.watermark.high`::

Controls the high watermark. It defaults to `90%`, meaning that
Elasticsearch will attempt to relocate shards away from a node whose disk
{es} will attempt to relocate shards away from a node whose disk
usage is above 90%. It can also be set to an absolute byte value (similarly
to the low watermark) to relocate shards away from a node if it has less
than the specified amount of free space. This setting affects the
allocation of all shards, whether previously allocated or not.

[[cluster-routing-flood_stage]]
`cluster.routing.allocation.disk.watermark.flood_stage`::
+
--
Controls the flood stage watermark. It defaults to 95%, meaning that
Elasticsearch enforces a read-only index block
Controls the flood stage watermark, which defaults to 95%. {es} enforces a read-only index block
(`index.blocks.read_only_allow_delete`) on every index that has one or more
shards allocated on the node that has at least one disk exceeding the flood
stage. This is a last resort to prevent nodes from running out of disk space.
The index block is automatically released once the disk utilization falls below
shards allocated on the node, and that has at least one disk exceeding the flood
stage. This setting is a last resort to prevent nodes from running out of disk space.
The index block is automatically released when the disk utilization falls below
the high watermark.

NOTE: You can not mix the usage of percentage values and byte values within
these settings. Either all are set to percentage values, or all are set to byte
values. This is so that we can we validate that the settings are internally
consistent (that is, the low disk threshold is not more than the high disk
threshold, and the high disk threshold is not more than the flood stage
threshold).
NOTE: You cannot mix the usage of percentage values and byte values within
these settings. Either all values are set to percentage values, or all are set to byte
values. This enforcement is so that {es} can validate that the settings are internally
consistent, ensuring that the low disk threshold is less than the high disk
threshold, and the high disk threshold is less than the flood stage
threshold.

An example of resetting the read-only index block on the `twitter` index:

Expand All @@ -63,7 +63,7 @@ PUT /twitter/_settings

`cluster.info.update.interval`::

How often Elasticsearch should check on disk usage for each node in the
How often {es} should check on disk usage for each node in the
cluster. Defaults to `30s`.

`cluster.routing.allocation.disk.include_relocations`::
Expand Down