Skip to content

Commit

Permalink
Update Elasticsearch automatic watermark change
Browse files Browse the repository at this point in the history
  • Loading branch information
mincong-h committed Aug 20, 2023
1 parent 2bdd0f3 commit 71dde2a
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions _posts/2021-04-10-disk-watermarks-in-elasticsearch.md
Original file line number Diff line number Diff line change
Expand Up @@ -144,8 +144,8 @@ The solutions for solving this issue are the same as the solutions for the low d

The next level is the flood stage. The default value is 95%. Elasticsearch 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, and that has at least one disk exceeding the flood stage. This setting is the last resort to prevent nodes from running out of disk space. Depending on your Elasticsearch version, the release mechanism is different:

* Before Elasticsearch 7, the index block must be released <mark>manually</mark> when the disk utilization falls below the high watermark.
* Since Elasticsearch 7, the index block is <mark>automatically</mark> released when the disk utilization falls below the high watermark.
* Before Elasticsearch 7.4, the index block must be released <mark>manually</mark> when the disk utilization falls below the high watermark.
* Since Elasticsearch 7.4, the index block is <mark>automatically</mark> released when the disk utilization falls below the high watermark. This is mentioned in the 7.4 breaking changes docs under the [Allocation Changes section](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/breaking-changes-7.4.html#_auto_release_of_read_only_allow_delete_block). Special thanks to Peter Dyson for pointing this out.

![Diagram for flood-stage disk watermark](/assets/20210410-Elasticsearch-Disk-Warkermarks-Diagram.flood-stage-watermark.png)

Expand Down

0 comments on commit 71dde2a

Please sign in to comment.