More read-only-allow-delete docs (#45320)

Adds to the `index.blocks.read_only_allow_delete` docs the information that
this block may be added or removed automatically, and rewords the
breaking-changes docs to mention the blocks explicitly and to recommend using a
different block.

Relates #42559
This commit is contained in:
David Turner 2019-08-08 09:58:23 +01:00 committed by GitHub
parent 9f62c04637
commit ddcc38cf1c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 18 additions and 15 deletions

View File

@ -166,8 +166,10 @@ specific index module:
allow writes and metadata changes. allow writes and metadata changes.
`index.blocks.read_only_allow_delete`:: `index.blocks.read_only_allow_delete`::
Identical to `index.blocks.read_only` but allows deleting the index to free
up resources. 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.
`index.blocks.read`:: `index.blocks.read`::

View File

@ -99,14 +99,17 @@ wait for the rerouting process to completely finish you should add the
[float] [float]
==== Auto-release of read-only-allow-delete block ==== Auto-release of read-only-allow-delete block
If a node exceeds the flood-stage disk watermark then we add a block to all of If a node exceeds the flood-stage disk watermark then {es} adds the
its indices to prevent further writes as a last-ditch attempt to prevent the `index.blocks.read_only_allow_delete` block to all of its indices to prevent
node completely exhausting its disk space. In earlier versions this block would further writes, as a last-resort attempt to prevent the node completely
remain in place until manually removed, causing confusion for users who exhausting its disk space. In earlier versions this block would remain in place
currently have ample disk space and are not aware that they nearly ran out at until manually removed, causing confusion for users who currently have ample
some point in the past. From 7.4 onwards the block is automatically removed disk space and who are not aware that they nearly ran out at some point in the
when a node drops below the high watermark again, with the expectation that the past. From 7.4 onwards the block is automatically removed when the node drops
high watermark is some distance below the flood-stage watermark and therefore below the high watermark again, with the expectation that the high watermark is
the disk space problem is truly resolved. This behaviour can be disabled by some distance below the flood-stage watermark and therefore the disk space
setting the system property `es.disk.auto_release_flood_stage_block` to problem is truly resolved. Since this block may be automatically removed, you
`false`. can no longer rely on adding this block manually to prevent writes to an index.
You should use the `index.blocks.read_only` block instead. This behaviour can
be disabled by setting the system property
`es.disk.auto_release_flood_stage_block` to `false`.

View File

@ -42,8 +42,6 @@ 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. 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 The index block is automatically released once the disk utilization falls below
the high watermark. the high watermark.
The automatic release can however be disabled in 7.x through a system property
`es.disk.auto_release_flood_stage_block`
NOTE: You can not mix the usage of percentage values and byte values within 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 these settings. Either all are set to percentage values, or all are set to byte