Elasticsearch节点磁盘空间耗尽

清理Elasticsearch占用的内存和磁盘空间 ELK中的Kibana连不上Elasticsearch了,提示Cannot connect to the Elasticsearch cluster,检查发现OutOfMemoryError,通过删除历史索引,达到清理Elasticsearch占用的内存和磁盘空间的目的 阅读详情
       最近遇到了一个特殊的情况,我们所使用的一个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 ]] [MergeException[java.io.IOException: There is not enough space on the disk]; nested: IOException[There is not enough space on the disk]; ]]

[2017-03-22 11:57:36,883][WARN ][indices.cluster          ] [ES-Data_IN_12] [[raws_v3.2017_03_22][1]] marking and sending shard failed due to [failed to create shard]
org.elasticsearch.index.shard.IndexShardCreationException: [raw_v3.2017_03_22][1] failed to create shard
Caused by: org.apache.lucene.store.LockObtainFailedException:
Can't lock shard [raw_v3.2017_03_22][1] , timed out after 5000ms

[2017-03-22 11:57:37,883][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[INITIALIZING], unassigned_info[[reason=ALLOCATION_FAILED], at[2017-03-22T11:57:31.677Z], details[shard failure [engine failure, reason [merge exception]][MergeException[java.io.IOException: There is not enough space on the disk]; nested: IOException[There is not enough space on the disk]; ]]], indexUUID [2Z-UtAr8Qx2h6Xe9BkxvAA], reason [shard failure [failed to create shard][IndexShardCreationException[[raw_v3.2017_03_22][1] failed to create shard]; nested: LockObtainFailedException[Can't lock shard [raw_v3.2017_03_22][1], timed out after 5000ms]; ]]

[2017-03-22 11:58:36,308][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[INITIALIZING], unassigned_info[[reason=ALLOCATION_FAILED], at[2017-03-22T11:58:20.607Z], details[shard failure [failed to create shard][IndexShardCreationException[[raw_v3.2017_03_22][1] failed to create shard]; nested: LockObtainFailedException[Can't lock shard [raw_v3.2017_03_22][1], timed out after 5000ms]; ]]], indexUUID [2Z-UtAr8Qx2h6Xe9BkxvAA], reason [shard failure [failed to create shard][IndexShardCreationException[[raw_v3.2017_03_22][1] failed to create shard]; nested: LockObtainFailedException[Can't lock shard [raw_v3.2017_03_22][1], timed out after 5000ms]; ]]

[2017-03-22 11:59:57,286][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[INITIALIZING], unassigned_info[[reason=ALLOCATION_FAILED], at[2017-03-22T11:59:41.200Z], details[shard failure [failed to create shard][IndexShardCreationException[[raw_v3.2017_03_22][1] failed to create shard]; nested: LockObtainFailedException[Can't lock shard [raw_v3.2017_03_22][1], timed out after 5000ms]; ]]], indexUUID [2Z-UtAr8Qx2h6Xe9BkxvAA], reason [master [ES-Data_IN_11][1_-exjNlSsi7h_0lJYCoRA][RD0003FF7D543F][inet[/100.117.132.72:9300]]{fault_domain=2, update_domain=11, data=false, master=true}
marked shard as initializing, but shard is marked as failed, resend shard failure ]

[2017-03-22 12:32:00,716][WARN ][index.engine             ] [ES-Data_IN_12] [raw_v3.2017_03_22][0] failed to sync translog

[2017-03-22 12:32:00,872][WARN ][indices.cluster          ] [ES-Data_IN_12] [[raw_v3.2017_03_22][0]] marking and sending shard failed due to [failed recovery] org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [raw_v3.2017_03_22][0] failed to recover shard

[2017-03-22 12:33:55,854][WARN ][cluster.action.shard     ] [ES-Data_IN_11] [raw_v3.2017_03_22][0] received shard failed for [raw_v3.2017_03_22][0], node[h9d1tKJFRtmg1aG-VMkA4A], [P], s[INITIALIZING], unassigned_info[[reason=ALLOCATION_FAILED], at[2017-03-22T12:32:01.410Z], details[shard failure [failed recovery][IndexShardGatewayRecoveryException[[raw_v3.2017_03_22][0] failed to recover shard]; nested: TranslogCorruptedException[translog corruption while reading from stream]; nested: ElasticsearchIllegalArgumentException[No version type match [46]]; ]]], indexUUID [2Z-UtAr8Qx2h6Xe9BkxvAA], reason [shard failure [failed recovery][IndexShardGatewayRecoveryException[[raw_v3.2017_03_22][0] failed to recover shard]; nested: TranslogCorruptedException[translog corruption while reading from stream]; nested: ElasticsearchIllegalArgumentException[No version type match [46]]; ]]

         从上面列出的日志不难看出,当节点ES-Data_IN_12的磁盘空间耗尽时,首先出现反应出问题的是后台运行的segment merge操作,因为segment merge需要额外的空间存储merge的结果。磁盘的耗尽也造成了translog的损坏,似乎Elasticsearch无法自动修复。根据#12055的讨论,手动删除.recovering文件可以解决这个问题,但是本人没有尝试过。最后需要指出的是,如果有replica在,可能情况就不是这样。我们索引之所以会RED,是因为一开始创建时唯一的replica没有被分配到任何机器上一直处于unassigned状态,所以在primary也出现问题时,就会没有可用的备份了。
       简单总结一下, Elasticsearch是基于Lucene的分布式索引系统,它以来本地的文件系统来存储Lucene文件,所以存储空间大小对于Elasticsearch至关重要。Elasticsearch提供了cluster.routing.allocation.disk.watermark.low来控制使用了存储空间多少时才分配shard到该节点上,其默认值为85%。




ElasticSearch的相关原理(zen节点发现机制,分片分配,故障转移,分片工作,分词原理) ElasticSearch的相关原理 节点的发现机制(zen机制) Zen机制是elasticsearch的内置机制,用于节点发现.所有节点间通讯必须用trasport模块来完成。 集群中的节点相互发现集群 负责master选举 Master选举机制 Master选举是由master-eligble节点发起的,当一个master-eligble发现满足以下条件的时候,发起选举 ①本master-eligble不是master ②本master-eligble节点通过zen模块的ping操作询问其他已 阅读详情

相关推荐

inode节点耗尽故障处理

问题描述: 磁盘还有容量,却创建不了文件 [root@localhost test]# df -h 文件系统 容量 已用 可用 已用% 挂载点 /dev/sda3 56G 8.0G 48G 15% / devtmpfs 898M 0 898M 0% /dev tmpfs 912M 0 912M 0% /dev/shm tmpfs 912M 9.2M 903M 2% /ru

白雪滑落树梢 2374

Elasticsearch 磁盘空间异常排查过程

分片大小差不多的情况下,节点 76 的分片数还比别的节点还少 10 个左右,它的磁盘空间反而多占用了 8TB。这是不是太奇怪了?事出反常必有妖,继续往下查。

yonggeit的博客 4024

linux 模拟硬盘满,Linux模拟硬盘资源耗尽故障

Linux硬盘资源包括[容量]及[文件数量(i节点)]两种,接下来,我们来模拟一下这两种资源分别被耗尽的故障。环境搭建:添加一块硬盘sdb,并在其中划分一块15M大小的分区/dev/sdb1,并将分区挂载至/mnt/111下。最后的挂载情况:[root@localhost ~]# df -m #查看容量Filesystem 1M-blocks Used ...

weixin_30769779的博客 1621

Elasticsearch集群中节点磁盘空间不足如何处理?

**摘要: Elasticsearch集群节点磁盘空间不足时,会触发水位线机制导致数据无法写入。常见原因包括磁盘使用率过高、索引未及时清理、数据量激增或分片分配不均衡。可通过以下方法处理: 释放空间:删除过期索引,清理临时文件; 临时调整水位线:提高阈值以应急; 扩展节点:添加新数据节点分担负载; 优化分片:重新分配分片或启用自动均衡; 检查ILM策略:确保旧索引按时删除。需结合监控与日志排查具体原因,优先通过清理数据或扩容解决根本问题。

公众号:AI前沿侦探 345

Elasticsearch磁盘空间爆满及 java_pid*.hprof 处理

Elasticsearch磁盘空间爆满及 java_pid*.hprof 处理

一个标题 4548

ELASTICSEARCHElasticSearch 磁盘满解决方案

详情: 查看es 状态命令: 通常用用_catAPI检测集群是否健康。 确保9200端口号可用:   curl 'localhost:9200/_cat/health?v'   绿色表示一切正常, 黄色表示所有的数据可用但是部分副本还没有分配,红色表示部分数据因为某些原因不可用. 2.通过如下语句,我们可以获取集群的节点列表:   curl 'localhost:92...

Zsigner的博客 7253

ElasticSearch实例磁盘占用率高 排查及解决方案

使用命令:curl -X PUT http://{ip}:9200/{index}/_settings --header ‘Content-Type: application/json’ -d ‘{“index”:{“number_of_replicas”:0}}’

sinat_36258805的博客 1505

ElasticSearch服务端报错:FileSystemException: No space left on device

摘要:Elasticsearch节点启动失败,报错显示磁盘空间不足。

weixin_42566359的博客 543

ELasticsearch】集群故障模拟方案(二):磁盘空间满、重选主节点

本文介绍了 Elasticsearch 集群故障模拟的两种场景:磁盘空间满和主节点选举问题。针对磁盘空间满模拟,详细说明了通过 dd 和 fallocate 命令快速填充磁盘的方法,对比了两种命令的差异及适用场景,同时提供了集群状态监控和清理方案。对于主节点选举问题,给出了识别主节点、停止主节点服务并观察选举过程的步骤。最后强调了安全注意事项和关键监控指标,为测试集群容错能力提供指导。全文包含具体命令示例和参数说明,适合运维人员参考实施。

Code · Cloud · Think · Repeat 1552

es集群一个节点多次重启问题分析

此时集群请求重新响应至该节点,待业务量逐渐上升至超过该es服务的承受能力,es服务又开始之前切换状态的操作,循环往复,直至集群的业务量下降,服务状态变为started并不再发生变化。1.节点的ram.percent内存使用率为99%和100%,合理的服务器内存使用率是60%~80%,超出正常使用范围。问题节点多次离线,因为主节点每30秒会去检查其他节点的状态,如果任何节点的垃圾回收时间超过30秒,查看节点日志未发现节点进程挂掉报错的原因,现场做了保活的操作,未手动启动关闭服务。由于es服务做了保活操作,

weixin_42106137的博客 810

Elasticsearch集群管理之1——如何高效的添加、删除节点

1、问题抛出 1.1 新增节点问题 我的群集具有黄色运行状况,因为它只有一个节点,因此副本保持未分配状态,我想要添加一个节点,该怎么弄? 1.2 删除节点问题 假设集群中有5个节点,我必须在运行时删除2节点。 那么如何在不影响指数的情况下完成? 我有接近10 Gbp/hour的连续数据流,这些数据正在连续写入并索引化。 重新平衡会对此有所影响吗? 本文就从上面两个问题说起,将相关知识点串起来,内...

铭毅天下Elasticsearch 2万+

Elasticsearch 索引的 read_only_allow_delete 属性详解与解决方案

Elasticsearch 中,是一种索引级别的设置,用于限制对索引的写操作,但允许删除操作。具体来说,当该设置为true时,索引会处于只读状态,无法执行新增或更新操作,但允许执行删除操作。这种机制通常用于防止误操作或意外修改,特别是在关键数据上。本文将详细介绍的作用、触发条件、解决方法以及如何避免此问题。是 Elasticsearch 中的一种保护机制,用于防止在磁盘空间不足的情况下对索引进行修改操作。通过合理的磁盘空间管理和预警机制,我们可以有效避免索引被设置为只读状态,并确保系统的稳定运行。

XMYX-0 2391

Linux Inodes耗尽处理

摘要: Linux系统中inodes(索引节点)用于存储文件元数据,当inodes耗尽时,即使磁盘空间充足也无法创建新文件,导致服务中断。常见原因包括文件系统配置不当、大量小文件积累、临时文件未清理等。排查方法包括使用df -i检查inodes使用率、定位高占用目录(如/var/log或/tmp)以及分析进程打开文件数(lsof)。

gongwanzhang的博客 1355

Elasticsearch磁盘警戒水位线机制

磁盘警戒水位线(Disk Watermark)是 Elasticsearch 用于防止节点磁盘空间不足导致故障的重要保护机制,它会根据磁盘使用情况自动控制分片分配行为。

Code · Cloud · Think · Repeat 1810

【ELK】ES新节点分配不平衡

【ELK】ElasticSearch 添加新节点时因分片大小分配不均分配不平衡

勤不了一点 2165

es磁盘满处理

curl -XGET 'http://192.168.0.131:9200/_cat/indices/?v' -uelastic 查询当前所有索引 could not store triggered watch with id [uJHz02SGQsmgOmEK1QkLdg_xpack_license_expiration_7447c0a1-2186-49fb-b7e1-332c47ada93...

linux_s2018的博客 4475

ES数据库节点故障处理:实战案例详解

通过真实案例解析es数据库节点异常的诊断与恢复过程,涵盖集群状态监控、分片重分配及数据安全保护策略,帮助运维人员快速应对es数据库故障,保障系统高可用。

weixin_35636570的博客 674

linux中ext4系统出现索引inode(索引节点)满,提示磁盘空间不足

一次在磁盘上建立文件夹的时候,报错提示设备上没有空间。但是df -h查看磁盘 [root@~]# pwd /data [root@~]# mkdir test mkdir: 无法创建目录 “test”: 设备上没有空间 查看系统磁盘情况: 问题:磁盘空间只使用了28%仍有剩余空间,但是建立文件和建立文件夹就是提示设备没有空间了。 分析:在磁盘上创建文件需要二个条件:1)磁盘空间

jaryle的专栏 6633
上一篇: Azure Stream Analytics的BadArgument错误
quicknet
博客等级 码龄25年 398粉丝 117原创
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值