即使我的索引中没有太多数据，也超出了高磁盘水印答案

【问题标题】：High disk watermark exceeded even when there is not much data in my index即使我的索引中没有太多数据，也超出了高磁盘水印
【发布时间】：2015-07-29 02:53:50
【问题描述】：

我在本地机器上使用 elasticsearch。数据目录只有 37MB 大小，但是当我查看日志时，我可以看到：

[2015-05-17 21:31:12,905][WARN][cluster.routing.allocation.decider] [Chrome] [h9P4UqnCR5SrXxwZKpQ2LQ][Chrome] 上超出 [h9P4UqnCR5SrXxwZKpQ2LQ][Chrome] 高磁盘水印 [10%]：5.7gb [ 6.1%]，分片将从该节点移出

对可能出现的问题感到非常困惑。有什么帮助吗？

【问题讨论】：

标签： elasticsearch

【解决方案1】：

来自Index Shard Allocation：

... watermark.high 控制高水印。默认为 90%，这意味着如果节点磁盘使用率超过 90%，ES 将尝试将分片重新定位到另一个节点。

实际索引的大小无关紧要；重要的是设备上剩余的可用空间。

如果默认值不适合您，您必须更改它们。

【讨论】：

哦！我真是太愚蠢了。谢谢！我刚刚检查了我的硬盘驱动器快满了
嘿，这是否与无法使用端口 5601 访问的 kibana 有关。我安装了弹性搜索和 kibana，但在弹性搜索日志中出现同样的错误，当我尝试使用 localhost:5601 访问 kibana 时，它不是显示任何东西
@MaheshMalpani 我可以在这里添加的不多，除了我建议您检查驱动器的可用磁盘空间。如果不是这种情况，我建议您进行更多研究并创建一个新问题。
使用设置“cluster.routing.allocation.disk.threshold_enabled: false”。能够清除阈值错误。
@MaheshMalpani 我面临同样的问题。您在哪里（哪个文件）对“cluster.routing.allocation.disk.threshold_enabled: false”进行了更改？？？

【解决方案2】：

解决问题，日志记录为：

超过高磁盘水印 [90%] [ytI5oTyYSsCVfrB6CWFL1g][ytI5oTy][/var/lib/elasticsearch/nodes/0] free: 552.2mb[4.3%]，分片会从这个节点搬走

您可以通过执行以下 curl 请求来更新阈值限制：

curl -XPUT "http://localhost:9200/_cluster/settings" \
 -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster": {
      "routing": {
        "allocation.disk.threshold_enabled": false
      }
    }
  }
}'

【讨论】：

也只需要附加-H 'Content-Type: application/json'
这取决于您的用例。默认情况下，您可以按照描述的方式使用它。快乐编码:)
@JaideepGhosh 我使用了这个命令curl -XPUT -H "Content-Type: application/json" https://[YOUR_ELASTICSEARCH_ENDPOINT]:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}' ，它可以工作，但是在一段时间后，它的索引空间又不够了，我必须再次点击命令......无论如何要修复这是永久的吗？

【解决方案3】：

这个来自Elasticsearch 6.4 docs 的稍微修改的 curl 命令对我有用：

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "2gb",
    "cluster.routing.allocation.disk.watermark.high": "1gb",
    "cluster.routing.allocation.disk.watermark.flood_stage": "500mb",
    "cluster.info.update.interval": "1m"
  }
}
'

如果 curl -XPUT 命令成功，您应该在 Elasticsearch 终端窗口中看到如下日志：

[2018-08-24T07:16:05,584][INFO ][o.e.c.s.ClusterSettings  ] [bhjM1bz] updating [cluster.routing.allocation.disk.watermark.low] from [85%] to [2gb]
[2018-08-24T07:16:05,585][INFO ][o.e.c.s.ClusterSettings  ] [bhjM1bz] updating [cluster.routing.allocation.disk.watermark.high] from [90%] to [1gb]
[2018-08-24T07:16:05,585][INFO ][o.e.c.s.ClusterSettings  ] [bhjM1bz] updating [cluster.routing.allocation.disk.watermark.flood_stage] from [95%] to [500mb]
[2018-08-24T07:16:05,585][INFO ][o.e.c.s.ClusterSettings  ] [bhjM1bz] updating [cluster.info.update.interval] from [30s] to [1m]

https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html

【讨论】：

【解决方案4】：

这是一个警告，不会影响任何事情。存储处理器 (SP) 使用高水位线和低水位线来确定何时刷新其写入缓存。可能的解决方案是释放一些内存

警告将消失。即使显示出来，副本也不会分配给可以的节点。 elasticsearch 可以正常工作。

【讨论】：

你是指内存还是磁盘？
与此观点相反，如果没有更多节点可以迁移，此警告不会消失。我运行一个本地 ES 集群进行开发，并且只有 1 个节点无法将其移动到任何地方。它最终引发了一个错误，因为我的索引是只读的，因为超出了此警告指示的限制。

【解决方案5】：

我使用绝对值和上升值代替百分比来更好地利用空间（在预生产中）：

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.threshold_enabled": true,
    "cluster.routing.allocation.disk.watermark.low": "1g",
    "cluster.routing.allocation.disk.watermark.high": "500m",
    "cluster.info.update.interval": "5m" 
  }
}

我还减少了池化间隔以使 ES 日志更短))

【讨论】：

【解决方案6】：

清理硬盘上的一些空间，这应该可以解决问题。这也会将您的 ES 集群的健康状况从黄色更改为绿色（如果您遇到上述问题，您很可能也会面临黄色集群健康问题）。

【讨论】：