Elasticsearch节点磁盘空间耗尽

最新推荐文章于 2025-05-19 10:06:32 发布
原创 最新推荐文章于 2025-05-19 10:06:32 发布 · 1.6w 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文描述了一个Elasticsearch集群中数据节点磁盘空间耗尽导致的严重后果，包括数据损坏和集群状态变为RED。日志显示，磁盘空间不足影响了segment merge操作和translog的完整性，可能导致数据丢失。根据社区讨论，手动删除.recovering文件可能是恢复的一种方法，但未实际验证。由于缺乏副本，当主节点出现问题时，没有备份可用。Elasticsearch依赖本地文件系统存储Lucene文件，因此磁盘空间管理至关重要，可通过cluster.routing.allocation.disk.watermark.low设置来控制。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

       最近遇到了一个特殊的情况，我们所使用的一个Elasticsearch集群的数据节点磁盘空间耗尽(out of space)，啥事会发生呢？ 数据损坏，集群RED。下面是相关的日志信息，我将其中一些关键点日志信息重点小时。这里 ES-Data_IN_11是当时的Master节点，ES-Data_IN_12是出现的磁盘耗尽的数据节点，出事儿的index名字为raw_v3.2017_03_22，我们仍然使用的是Elasticsearch 1.7.2。

[2017-03-22 11:57:30,503][WARN ][index.merge.scheduler ] [ES-Data_IN_12] [raw_v3.2017_03_22][1] failed to merge

[2017-03-22 11:57:30,646][WARN ][index.engine ] [ES-Data_IN_12] [raw_v3.2017_03_22][1] failed engine [merge exception]

[2017-03-22 11:57:30,663][WARN ][indices.cluster ] [ES-Data_IN_12] [[raw_v3.2017_03_22][1]] marking and sending shard failed due to [engine failure, reason [merge exception]]

[2017-03-22 11:57:31,677][WARN ][cluster.action.shard ] [ES-Data_IN_11] [raw_v3.2017_03_22][1] received shard failed for [raw_v3.2017_03_22][1], node[h9d1tKJFRtmg1aG-VMkA4A], [P], s[STARTED], indexUUID [2Z-UtAr8Qx2h6Xe9BkxvAA], reason [shard failure [engine failure, reason [merge exception <
最低0.47元/天 解锁文章
quicknet
关注
清理Elasticsearch占用的内存和磁盘空间
laolitou_1024的博客
03-22 4553
ELK中的Kibana连不上Elasticsearch了，提示Cannot connect to the Elasticsearch cluster，检查发现OutOfMemoryError，通过删除历史索引，达到清理Elasticsearch占用的内存和磁盘空间的目的
Elasticsearch index read-only 问题解决办法（ES磁盘满或满扩容之后处理）
qq_24078621的博客
09-27 3497
背景：同事同步商品的es时，总是报index read-only。如下图。 然后各种排查，先看了一下es的数据节点磁盘已经满了。大部分都是日志数据。先删除日志数据。然后还是报这种错。 原因：当存储空间使用超过95%时，elasticsearch会将索引设置为只读模式，所以新产生的日志不能入库，也不能清除。因为商品和日志都是用的同一个es,导致同步商品也有问题。 解决：curl -XPUT -H “Content-Type: application/json” http://${ip}:9200/.
如何优化 Elasticsearch 磁盘空间和使用情况
最新发布
Elastic 中国社区官方博客
05-19 1308
文章由Elastic的Kofi Bartlett撰写，主要讨论了如何有效管理和优化Elasticsearch中的磁盘空间使用。文章首先强调了磁盘管理的重要性，指出磁盘空间不足会导致数据写入停止，而过度分配则会造成资源浪费。接着，文章介绍了Elasticsearch中的水位线阈值，包括低磁盘水位线、高磁盘水位线阈值和磁盘洪水阶段，这些阈值帮助监控磁盘使用情况。文章还提供了处理磁盘过满的几种方法，如删除旧数据、增加存储容量、使用快照与还原技术、减少分片副本数以及设置磁盘使用告警。此外，文章还探讨了如何减少未被充
elasticsearch7.15节点磁盘空间满了迁移数据到新磁盘
TanYYF的专栏
04-21 512
在 Elasticsearch 中设置某个节点临时不可用（例如进行维护或升级），可以通过以下步骤安全地操作，避免数据丢失或集群状态异常。主节点（Master Node）：如果目标节点是主节点，确保集群中还有其他可用主节点。强制停机风险：直接关闭节点而不迁移分片可能导致集群变黄/红（部分数据不可用）。执行后，Elasticsearch 会开始将此节点上的分片迁移到其他节点。说明：禁用分片自动分配，避免节点下线时触发数据迁移。说明：恢复分片自动分配，允许集群重新平衡数据。5.维护完成后恢复节点。
Elasticsearch磁盘空间爆满及 java_pid*.hprof 处理
一个标题
02-28 4025
Elasticsearch磁盘空间爆满及 java_pid*.hprof 处理
【ElasticSearch】6.7.1版本磁盘满了无法写入数据
gong_yangyang的博客
12-15 623
由于服务器磁盘达到95%，导致索引不可写；
深入解读 Elasticsearch 磁盘水位设置
醉鱼的博客
03-10 2036
到了这，还记得我们的问题吗，就是说 Elasticsearch 是怎么判定的磁盘超出设定的阈值的呢？左右，所以按照 Elasticsearch 的设定，ES 中分片应该是无法分配的。，可以看到，当前类中出现了两次，根据日志打印的其他信息不难发现，对于此处就是。是的你没猜错，通过这个位置你就可以知道是哪个方法调用的这，我们点一下。阈值时，对于新创建的索引主分片不影响，副本分片受影响；判断，相信就是这了，我的感觉来了，没想到这个找起来这么简单。行方法的开头打一个断点，重启之后，进入断点之后的值如下。
【Elasticsearch 的内存和硬盘使用情况查询】
weixin_46356409的博客
08-13 3736
通过这些方法和工具，你可以有效地监控和管理 Elasticsearch 的内存和硬盘使用情况，确保其稳定运行。
当磁盘使用率达到此阈值时，Elasticsearch会将节点标记为不可分配，并尝试将所有分片从该节点移动到其他节点,节点上的分片设置为只读索引。默认值为95%，同样可以根据需要进行调整。防止磁盘空间耗尽最后的手段。当磁盘低于 high 水位时，索引块自动释放。
03-20
这一步骤仅移除只读标志并不解决根本原因——即实际可用空间不足的问题所以建议采取措施增加物理硬盘大小或是删除不必要的旧日志文件释放更多地方给 ES 使用[^2][^3]。 ### 总结 合理规划和监控各节点的磁盘利用率...
从ES的JVM配置起步思考JVM常见参数优化
热门推荐
张彦峰的博客
12-03 9万+
Java 8目前仍然是许多企业中主要使用的版本之一，尤其是对于比较保守的公司。在过去，CMS (Concurrent Mark-Sweep) 垃圾回收器在Java 8中是一种常见选择，因为它在某些场景下能够提供较好的性能。然而，随着Java版本的不断更新，一些旧的特性和组件被淘汰或替代，比如CMS。Java 14中正式废弃了CMS，而新的垃圾回收器，如ZGC和G1，逐渐成为了主流选择。ZGC和G1在处理大内存堆和低停顿时间方面表现出色，适用于现代应用程序的需求。
【ELASTICSEARCH】ElasticSearch 磁盘满解决方案
Zsigner的博客
09-07 7019
详情： 查看es 状态命令： 通常用用_catAPI检测集群是否健康。 确保9200端口号可用: 　　curl 'localhost:9200/_cat/health?v' 　　绿色表示一切正常, 黄色表示所有的数据可用但是部分副本还没有分配,红色表示部分数据因为某些原因不可用. 2.通过如下语句，我们可以获取集群的节点列表： 　　curl 'localhost:92...
elasticsearch磁盘空间满了故障处理思路
蘑菇丁的专栏
03-24 2万+
昨天接到客户投诉说ES数据目录已达到100%了，当时第一想法监控组怎么监控的80%报警为什么没有监控出啦，经问，监测组是几天前接到报警，并忽略了，我当时那个崩溃，并有想骂人的冲动，这是现网，不是测试时环境，竟然有这么不负责的同事我也是醉的，我登录服务器一看磁盘空间最糟的100%，另几个99%，刚搭建两个月的集群出现空间不足，当时说没有这么大的数据量，我自己给自己挖了一个大坑，把数据存在一个磁盘上。
elasticsearch磁盘超过80%后出现数据写不进去的问题
Subbe的博客
04-18 3470
1、原因：硬盘将近写满后，索引变为 read_only_allow_delete=true 只读状态，防止日志再写入。 2、解决： 清理磁盘，使占用低于80%。 扩大磁盘容量 3、需要手动修改索引状态 PUT _settings { "index": { "blocks": { "read_only_allow_delete": "false" } } } 也可使用postman等工具调用 ...
Elasticsearch 磁盘使用情况
我只是个小学生 能力有限 一直抱着学习的态度
11-13 2005
curl -XGET “http://localhost:9200/_cat/shards?v” curl -XGET localhost:9200/_cat/allocation?v
ElasticSearch实例磁盘占用率高 排查及解决方案
sinat_36258805的博客
10-25 1237
使用命令：curl -X PUT http://{ip}:9200/{index}/_settings --header ‘Content-Type: application/json’ -d ‘{“index”:{“number_of_replicas”:0}}’
ElasticSearch-磁盘空间不够引起的问题
mnasd的博客
01-25 3231
es 6.2.4版本 logstash跑了一阵子之后不再同步数据了,日志信息如下： [2019-06-19T10:30:28,379][INFO ][logstash.outputs.elasticsearch] retrying failed action with response code: 403 ({"type"=>"cluster_block_exception", "reason"=>"blocked by: [FORBIDDEN/12/index read-only /
ElasticSearch无法启动报设备上没有空间
ZRHZRHH的博客
02-22 1570
项目上ES无法启动，Linux系统，原因：ES所在存储空间已满 排查：使用 df -h 定位系统资源，将无用资源删除，释放资源。
Linux下安装Elasticsearch
lljddddd的博客
11-15 991
Linux安装单机版Elasticsearch
Elasticsearch 磁盘空间异常排查过程
yonggeit的博客
08-12 1255
分片大小差不多的情况下，节点 76 的分片数还比别的节点还少 10 个左右，它的磁盘空间反而多占用了 8TB。这是不是太奇怪了？事出反常必有妖，继续往下查。
elasticsearch节点在线为什么没用分片
12-27
### Elasticsearch 节点在线但未使用分片的原因 当Elasticsearch节点处于在线状态却并未使用任何分片时，可能由多种因素造成。一种情况是该节点被配置为专门的角色节点，比如协调节点(coordinating only)，这种类型的节点不存储数据也不参与选举主节点的过程[^3]。 另一种可能性在于集群层面的设置或是特定索引级别的 shard allocation filter 导致新创建的数据分片无法分配到此节点上。这可能是由于设置了诸如 awareness 属性来控制副本如何分布于不同属性标签下的节点之间；或者是通过 `index.routing.allocation.*` 参数指定了某些条件限制了哪些节点能够接收某个具体索引的新建或已存在的分片[^2]。 另外，在多数据中心部署场景下，为了防止跨广域网络传输带来的延迟影响性能表现以及增加成本开销，通常会利用 zone-awareness 功能将同属一个地理区域内的机器组成一个小范围内的子集来进行更高效的读写操作。此时即使目标节点健康可用也可能因为不符合上述策略而未能接收到相应的分片任务[^4]。 最后还有一种较为少见的情况就是磁盘空间不足、文件描述符耗尽等问题也会阻止新的分片分配给当前节点，尽管它看起来是在正常工作的状态下[^1]。 #### 解决方案 针对以上提到的各种原因，可以采取如下措施： 对于仅作为协调角色使用的节点无需特别处理，除非业务需求发生变化需要调整其职能定位，则应修改对应的 node attributes 配置项使其具备其他能力。 若是由于 shard allocation filters 设置不当引起的问题，建议检查现有过滤规则是否合理，并依据实际情况适当放宽这些约束以便让更多的资源得到充分利用。可以通过更新相关参数如 `cluster.routing.allocation.awareness.attributes` 来实现这一点。 如果是出于高可用性和灾难恢复考虑所设计的数据中心感知机制造成的，则需评估整体架构布局合理性的同时兼顾局部优化的可能性，确保各部分之间的协作顺畅高效。必要时可借助专用插件完成更加精细复杂的调度逻辑定制化开发工作。 至于硬件资源瓶颈方面的影响，定期监控各项指标变化趋势有助于提前预警潜在风险点所在位置进而及时作出响应动作加以缓解压力。例如清理不必要的日志记录减少占用量、申请扩容升级基础设施等都是可行的办法之一。 ```bash GET /_cat/shards?v=true&s=state POST _cluster/reroute?retry_failed=true PUT /my-index/_settings { "settings": { "number_of_replicas": 0, "routing.allocation.include._name": "node_name" } } ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值