Elasticsearch 磁盘空间异常：一次成功的故障排除案例分享

最新推荐文章于 2024-11-15 18:55:11 发布
原创 最新推荐文章于 2024-11-15 18:55:11 发布 · 705 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#elasticsearch #大数据 #搜索引擎 #Easysearch

故障现象

近日有客户找到我们，说有个 ES 集群节点，磁盘利用率达到了 82% ，而其节点才 63% ，想处理下这个节点，降低节点的磁盘利用率。

起初以为是没有打开自动平衡导致的，经查询，数据还是比较平衡的。

利用率较高的是 76 节点，如果 76 节点的分片比其他节点多，好像还比较合乎逻辑，但它反而比其他节点少了 12-15 个分片。那是 76 节点上的分片比较大？

索引情况


图中都是较大的索引，1 个索引 25TB 左右，共 160 个分片。

分片大小

节点 64

节点 77

节点 75

问题节点 76

可以看出分片大小没有出现较大的倾斜，分片大小和数据平

最低0.47元/天 解锁文章
INFINI Labs
关注
Elasticsearch 磁盘空间异常排查过程
yonggeit的博客
08-12 1300
分片大小差不多的情况下，节点 76 的分片数还比别的节点还少 10 个左右，它的磁盘空间反而多占用了 8TB。这是不是太奇怪了？事出反常必有妖，继续往下查。
ElasticSearch 因为磁盘空间不够引起的数据插入错误
Guizy
06-02 2848
错误描述: ElasticSearch 因为磁盘空间不够引起的数据插入错误。（message [ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]]） 当使用Logstash将MySQL中的数据采用到ES索引中: 出现以下问题, 昨天还可以正常采集mysql数据库中的信息, 今天报了错,解决方案如下: 问题原因: 索引变成了只读 index read-only / allow del
es磁盘满处理
linux_s2018的博客
12-27 4413
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...
Elasticsearch磁盘空间爆满及 java_pid*.hprof 处理
一个标题
02-28 4241
Elasticsearch磁盘空间爆满及 java_pid*.hprof 处理
ElasticSearch-磁盘空间不够引起的问题
mnasd的博客
01-25 3299
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 /
【故障快速诊断】：云总线平台故障排除与解决案例
![【故障快速诊断】：云总线平台故障排除与解决案例]...在这一章节中，我们将简要介绍云总线平台故障排除的概念、重要性以及它在I
FABmaster项目应用深度剖析：案例分析与故障排除技巧
[FABmaster项目应用深度剖析：案例分析与故障排除技巧](https://opengraph.githubassets.com/455677b6c7eb1c8eb0c38fb9f581444401306f00732c53ede9e86b981dd2413e/zly666666/Mechanical-fault-diagnosis) ...
分布式文件系统的维护与监控：案例研究及故障排除策略
本文综合介绍了分布式文件系统的设计、维护、监控以及故障排查的关键技术，并展望了其未来发展趋势。第一章概述了分布式文件系统的基本架构和运作原理。第二章探讨了系统的维护策略，重点分析了系统架构优化、维护...
Linux系统日志分析：从监控到故障排除，深入了解系统运行状况（3个实战案例）
这些日志提供了一个宝贵的窗口，用于了解系统的运行状况、诊断问题和进行故障排除。 系统日志通常存储在`/var/log`目录下，其中包含大量文件，每个文件记录特定类型的事件。例如，`/var/log/messages`包含来自各种...
ElasticSearch实例磁盘占用率高 排查及解决方案
sinat_36258805的博客
10-25 1397
使用命令：curl -X PUT http://{ip}:9200/{index}/_settings --header ‘Content-Type: application/json’ -d ‘{“index”:{“number_of_replicas”:0}}’
elasticsearch磁盘空间满了故障处理思路
蘑菇丁的专栏
03-24 2万+
昨天接到客户投诉说ES数据目录已达到100%了，当时第一想法监控组怎么监控的80%报警为什么没有监控出啦，经问，监测组是几天前接到报警，并忽略了，我当时那个崩溃，并有想骂人的冲动，这是现网，不是测试时环境，竟然有这么不负责的同事我也是醉的，我登录服务器一看磁盘空间最糟的100%，另几个99%，刚搭建两个月的集群出现空间不足，当时说没有这么大的数据量，我自己给自己挖了一个大坑，把数据存在一个磁盘上。
【ElasticSearch】6.7.1版本磁盘满了无法写入数据
gong_yangyang的博客
12-15 653
由于服务器磁盘达到95%，导致索引不可写；
Elasticsearch 查看磁盘占用 查看指定索引磁盘占用
csdn565973850的博客
11-15 2188
考虑到既然数据要放在 es 中，那么相应的数据量往往都不会小，那么在对这些数据进行大批量的变动时，带来的磁盘问题也就需要考虑了，比如当你需要对一个十几G数据量的索引进行迁移复制时，那么对于磁盘的占用就会很大，这个时候就需要提前了解一下磁盘占用情况。
清理Elasticsearch占用的内存和磁盘空间
laolitou_1024的博客
03-22 5048
ELK中的Kibana连不上Elasticsearch了，提示Cannot connect to the Elasticsearch cluster，检查发现OutOfMemoryError，通过删除历史索引，达到清理Elasticsearch占用的内存和磁盘空间的目的
Elasticsearch index read-only 问题解决办法（ES磁盘满或满扩容之后处理）
qq_24078621的博客
09-27 3630
背景：同事同步商品的es时，总是报index read-only。如下图。 然后各种排查，先看了一下es的数据节点磁盘已经满了。大部分都是日志数据。先删除日志数据。然后还是报这种错。 原因：当存储空间使用超过95%时，elasticsearch会将索引设置为只读模式，所以新产生的日志不能入库，也不能清除。因为商品和日志都是用的同一个es,导致同步商品也有问题。 解决：curl -XPUT -H “Content-Type: application/json” http://${ip}:9200/.
Elasticsearch节点磁盘空间耗尽
Jeffrey Zhou 的专栏
03-23 1万+
最近遇到了一个特殊的情况，我们所使用的一个Elasticsearch集群的数据节点磁盘空间耗尽，啥事会发生呢？ 当然你的RED。下面是相关的日志信息，其中ES-Data_11是当时的Master节点，ES-Data_12是出现的磁盘耗尽的数据节点，出事儿的index名字为raw_v3.2017_03_22。 [2017-03-22 11:57:30,503][WARN ][index
ElasticSearch分片不均匀，集群负载不均衡
热门推荐
scalad
06-02 3万+
ElasticSearch负载不均衡某天晚上，服务器告警，发现服务器接口出现很多400，初步定为是ES服务器CPU达到了98%以上，ES日志出现了很多错误日志，具体如下：参考https://blog.youkuaiyun.com/wwd0501/article/details/78399943也就是Elasticsearch在并发查询量大的情况下，访问流量超过了集群中单个Elasticsearch实例的处理能...
elasticSearch7.9数据占用磁盘存储空间情况
晓缔的专栏
10-09 795
es数据占用存储空间
解决 Elasticsearch 写操作磁盘空间问题——cluster_block_exception
后端开发
08-14 1471
在运行 Elasticsearch 集群遇到磁盘空间不足的情况时，Elasticsearch 会采取保护措施以防止数据丢失。错误，特别是当错误消息表明索引被设置为只读模式时。
Elasticsearch集群故障恢复的最佳实践有哪些？
最新发布
11-26
<think> 我们正在讨论Elasticsearch集群故障恢复的最佳实践。根据引用内容，我们可以从以下几个方面展开： 1. 集群设计阶段的高可用性考虑（如节点角色分配、分片副本策略） 2. 故障预防措施（如文件描述符设置） 3. 实际故障恢复操作（如修改集群设置、调整超时参数等） 4. 集群配置管理（如hosts配置，节点通信） 结合引用材料： - 引用[1]强调了集群设计与管理的重要性，包括节点角色、分片副本、健康检查、扩容降级策略等。 - 引用[2]提醒注意文件描述符设置，避免因此导致数据丢失。 - 引用[3]给出了集群节点配置的示例（/etc/hosts配置节点IP和主机名）。 - 引用[4]展示了通过集群设置调整搜索超时和限制昂贵查询，这是故障隔离的一种手段。 因此，在回答中，我们将涵盖： 1. 预防性设计（高可用架构） 2. 监控与预警 3. 常见故障恢复步骤 4. 集群配置检查 5. 灾难恢复机制 同时，我们将按照最佳实践的结构进行组织，并添加示例代码和配置片段。 </think> ### Elasticsearch集群故障恢复最佳实践 基于高可用架构设计[^1]，以下是Elasticsearch集群故障恢复的系统性方案： --- #### 一、预防性设计（**根本性防护**） 1. **节点角色隔离** ```yml # elasticsearch.yml node.roles: [ data, ingest ] # 数据节点 node.roles: [ master ] # 专用主节点 node.roles: [ ml, remote_cluster ] # 专用协调节点 ``` - 分离主节点/数据节点角色，避免单点故障[^1] - **效果**：主节点故障时数据节点仍可读写 2. **分片副本策略** ```bash # 设置最小副本数（保证高可用） PUT /_cluster/settings { "persistent": { "index.unassigned.node_left.delayed_timeout": "5m", "cluster.routing.allocation.enable": "all" } } ``` - 副本数 ≥ 2（N+2冗余） - 跨机架/可用区分片分配（`cluster.routing.awareness`）[^1] 3. **文件描述符优化** ```bash # 避免描述符耗尽导致灾难（引用[2]） ulimit -n 65536 # Linux临时生效 /etc/security/limits.conf: elasticsearch - nofile 65536 ``` **监控命令**： ```bash GET /_nodes/stats/process?filter_path=**.max_file_descriptors ``` --- #### 二、故障检测与隔离 1. **健康检查自动化** ```bash # 集群状态API（实时检测） GET /_cluster/health?timeout=5s # 关键指标阈值： - status: RED（立即告警） - unassigned_shards > 0（需干预） ``` 2. **故障节点隔离** ```bash # 排除故障节点（防止拖垮集群） PUT /_cluster/settings { "transient": { "cluster.routing.allocation.exclude._ip": "192.168.66.151" } } ``` 3. **查询熔断机制** ```bash # 限制高消耗查询（引用[4]） PUT /_cluster/settings { "transient": { "search.default_search_timeout": "30s", "indices.breaker.fielddata.limit": "60%" } } ``` --- #### 三、恢复操作流程 **场景1：节点宕机恢复** ```mermaid graph TD A[检测节点失联] --> B{主节点存活？} B -->|是| C[自动重路由分片] B -->|否| D[手动选举新主节点] C --> E[等待副本数据同步] D --> F[恢复宕机节点后重加入集群] ``` **场景2：数据分片损坏** 1. 优先使用副本分片恢复 ```bash # 强制分配未分配分片 POST /_cluster/reroute?retry_failed=true ``` 2. 从快照恢复（终极手段） ```bash POST /_snapshot/my_backup/snapshot_1/_restore { "indices": "critical_index", "rename_pattern": "(.+)", "rename_replacement": "restored_$1" } ``` --- #### 四、灾备与演练 1. **定期快照策略** ```bash # 配置S3/MinIO快照仓库 PUT /_snapshot/my_s3_repository { "type": "s3", "settings": { "bucket": "es-backups" } } ``` - 频率：每小时增量 + 每日全量 2. **混沌工程测试** - 模拟场景： - 随机终止节点进程 - 网络分区（`iptables`阻断流量） - 磁盘写满 - 验证指标： - 分片恢复时间（目标 < 5分钟） - 数据一致性校验（`_cat/recovery?v`） --- #### 五、配置验证清单 | 项目 | 达标要求 | 检测命令 | |------|----------|----------| | 节点角色隔离 | 专用主节点≥3 | `GET /_cat/nodes?h=role,ip` | | 副本冗余 | 所有索引副本≥1 | `GET /_cat/indices?h=index,rep` | | 文件描述符 | ≥65536 | `GET /_nodes/stats/process` | | 快照有效性 | 最近24小时有成功快照 | `GET /_snapshot/_status` | > **案例**：某金融集群通过**角色隔离+跨机房副本**，主节点宕机后10秒内完成故障转移，数据零丢失[^1]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值