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:
parent
9f62c04637
commit
ddcc38cf1c
|
@ -166,8 +166,10 @@ specific index module:
|
|||
allow writes and metadata changes.
|
||||
|
||||
`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`::
|
||||
|
||||
|
|
|
@ -99,14 +99,17 @@ wait for the rerouting process to completely finish you should add the
|
|||
[float]
|
||||
==== 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
|
||||
its indices to prevent further writes as a last-ditch attempt to prevent the
|
||||
node completely exhausting its disk space. In earlier versions this block would
|
||||
remain in place until manually removed, causing confusion for users who
|
||||
currently have ample disk space and are not aware that they nearly ran out at
|
||||
some point in the past. From 7.4 onwards the block is automatically removed
|
||||
when a node drops below the high watermark again, with the expectation that the
|
||||
high watermark is some distance below the flood-stage watermark and therefore
|
||||
the disk space problem is truly resolved. This behaviour can be disabled by
|
||||
setting the system property `es.disk.auto_release_flood_stage_block` to
|
||||
`false`.
|
||||
If a node exceeds the flood-stage disk watermark then {es} adds the
|
||||
`index.blocks.read_only_allow_delete` block to all of its indices to prevent
|
||||
further writes, as a last-resort attempt to prevent the node completely
|
||||
exhausting its disk space. In earlier versions this block would remain in place
|
||||
until manually removed, causing confusion for users who currently have ample
|
||||
disk space and who are not aware that they nearly ran out at some point in the
|
||||
past. From 7.4 onwards the block is automatically removed when the node drops
|
||||
below the high watermark again, with the expectation that the high watermark is
|
||||
some distance below the flood-stage watermark and therefore the disk space
|
||||
problem is truly resolved. Since this block may be automatically removed, you
|
||||
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`.
|
||||
|
|
|
@ -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.
|
||||
The index block is automatically released once the disk utilization falls below
|
||||
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
|
||||
these settings. Either all are set to percentage values, or all are set to byte
|
||||
|
|
Loading…
Reference in New Issue