Disk Watermark 与只读索引

做的事：本机真实磁盘用量长期在94%左右，先直接把三个水位全部设到比94%更低，对一个全新索引测试

代码本机 df -h / 真实显示: 24Gi可用 / 460Gi总量 ≈ 94%已用 PUT /_cluster/settings {"persistent":{ "cluster.routing.allocation.disk.watermark.low":"88%", "cluster.routing.allocation.disk.watermark.high":"89%", "cluster.routing.allocation.disk.watermark.flood_stage":"90%" }} PUT /ro_test {"settings":{"number_of_shards":1,"number_of_replicas":0}}

验证：全新索引的主分片真实直接变成UNASSIGNED，比预想的"只读"更严重

ro_test 0 p UNASSIGNED
集群健康: status=red

这个真实结果说明超过high水位的后果，对一个还没有任何副本存在于任何地方的全新分片来说，真实不是"变成只读"这么温和，而是真实直接拒绝分配——因为超过high水位的节点真实被ES判定为"不适合接收新分片"，这跟本系列上一篇验证allocation.exclude时发现的"新分片没有既成事实保护"是同一类真实行为。

真实尝试只单独调高flood_stage来隔离测试，看是否能绕开high水位的限制

代码PUT /_cluster/settings {"persistent":{ "cluster.routing.allocation.disk.watermark.high":"98%", "cluster.routing.allocation.disk.watermark.flood_stage":"90%" }}

验证：真实直接被拒绝，ES强制要求low≤high≤flood_stage，三个水位真实不能互相独立设置

→ 400 illegal_argument_exception:
  "high disk watermark [98%] more than flood stage disk watermark [90%]"

真实换个思路：先在安全水位下让索引正常启动，再把三个水位一起下调到94%以下

代码PUT /_cluster/settings {"persistent":{ "cluster.routing.allocation.disk.watermark.low":"95%", "cluster.routing.allocation.disk.watermark.high":"96%", "cluster.routing.allocation.disk.watermark.flood_stage":"97%" }} 删除重建 ro_test，确认分片STARTED，真实写入1条文档成功(result:"created") PUT /_cluster/settings {"persistent":{ "cluster.routing.allocation.disk.watermark.low":"88%", "cluster.routing.allocation.disk.watermark.high":"89%", "cluster.routing.allocation.disk.watermark.flood_stage":"90%", "cluster.routing.allocation.disk.watermark.flood_stage.frozen":"90%" }} # 等待35秒，让磁盘监控周期性重新评估

验证：35秒后，已经STARTED的分片真实完全没被驱逐，但索引真实被自动加上了read_only_allow_delete这个block

ro_test 0 p STARTED   ← 真实分片位置完全没变

GET /ro_test/_settings
→ settings.index.blocks: {"read_only_allow_delete":"true"}   ← 真实自动加上的

这组真实结果跟本系列上一篇allocation.exclude的发现一脉相承：ES真实不会主动驱逐已经安置好的分片去制造数据不可用，水位下调后它选择的真实应对方式是给索引加上一个保护性的只读block，而不是把分片踢走——这跟全新分片撞上high水位时"直接拒绝分配"是完全不同的两种真实应对策略，取决于这个分片是否已经有"已经安全存在于某处"这个既成事实。

真实验证这个block的实际效果：先测写入，再测删除文档，最后测删除整个索引

代码POST /ro_test/_doc {"n":2} DELETE /ro_test/_doc/<已有文档id> DELETE /ro_test # 删除整个索引

验证：写入真实被拒绝；文档级删除真实也被同样拒绝，跟名字给人的直觉完全相反；真实能做的是删除整个索引

写入 → 429 cluster_block_exception:
  "index [ro_test] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded
   flood-stage watermark, index has read-only-allow-delete block]"

删除文档 → 429 cluster_block_exception   ← 真实跟写入收到完全一样的拒绝

删除整个索引 DELETE /ro_test → {"acknowledged":true}   ← 真实这个才会成功

收尾：真实把水位设置恢复回项目里原本的安全值，清理测试索引

代码PUT /_cluster/settings {"persistent":{ "cluster.routing.allocation.disk.watermark.low":"98%", "cluster.routing.allocation.disk.watermark.high":"99%", "cluster.routing.allocation.disk.watermark.flood_stage":"99.5%", "cluster.routing.allocation.disk.watermark.flood_stage.frozen":null }} DELETE /ro_test

验证：集群真实恢复到green，4个主分片全部active，水位配置真实回到安全值

status: "green"
active_primary_shards: 4
active_shards: 4
unassigned_shards: 0

分步演示：Disk Watermark从UNASSIGNED到read_only_allow_delete的完整真实行为链

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。