记录一次elasticsearch状态为red的问题修复

最新推荐文章于 2025-01-22 11:37:09 发布
原创 最新推荐文章于 2025-01-22 11:37:09 发布 · 526 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#elasticsearch #jenkins #大数据

本文记录了一次Elasticsearch集群健康值为红色的问题，问题源于translog文件损坏。通过删除translog文件和重置路由成功解决了恢复失败的问题。在执行删除操作前需谨慎，确保数据安全。解决方案包括使用curl发送HTTP请求进行路由重置。

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

问题描述

使用elasticsearch-head-master查看到集群健康值为**red(14 of 30)**。其中一个index的shard 2 恢复失败，失败原因描述如下。
failed shard on node [IEiX75zpThqncQK8SNAvcQ]: failed recovery, failure RecoveryFailedException[[tqmp][2]: Recovery failed on {node-1}{IEiX75zpThqncQK8SNAvcQ}{v1SutLQ0QLa-nA0BFhtucQ}{127.0.0.1}{127.0.0.1:9300}{ml.machine_memory=17179283456, xpack.installed=true, ml.max_open_jobs=20, ml.enabled=true}]; nested: IndexShardRecoveryException[failed to recover from gateway]; nested: EngineCreationFailureException[failed to create engine]; nested: TranslogCorruptedException[translog from source [D:\elasticsearch-6.8.5\data\nodes\0\indices\oNCtZsHNR4e_peCcHi-cuQ\2\translog\translog-69.ckp] is corrupted, checkpoint file translog-69.ckp already exists but has corrupted content: expected Checkpoint{offset=155, numOps=1, generation=69, minSeqNo=136, maxSeqNo=136, globalCheckpoint=135, minTranslogGeneration=69, trimmedAboveSeqNo=-2} but got Checkpoint{offset=55, n

最低0.47元/天 解锁文章

200万优质内容无限畅学
fly_1c
关注
5、elasticsearch监控告警
xuebo1129927648的博客
06-10 31
通过监控上述指标，可全面掌握 Elasticsearch 集群的健康状态、资源利用情况和性能瓶颈。建议结合。
4、elasticsearch性能优化
最新发布
xuebo1129927648的博客
06-10 31
Elasticsearch 的性能优化涉及多个层面，包括硬件配置、索引设计、查询优化、集群管理等。yamlpath.databashbash_sourcebashscroll APIbashbashsamplerbashbashyamlplaintextyamlyamlbashbash通过以上优化措施，可以显著提升 Elasticsearch 的性能和稳定性。实际优化时，建议从硬件、索引设计、查询模式三个方面入手，结合业务场景进行针对性调整。
Elasticsearch 集群状态恢复（RED 与 YELLOW）
天空之城
10-26 2517
分片未被分配原因有下列类型： INDEX_CREATED 由于 create index api 创建索引导致，索引创建过程中，把索引的全部分片分配完毕需要一个过程，在全部分片分配完毕之前，该索引会处于短暂的 RED 或 YELLOW 状态。因此监控系统如果发现集群 RED，不一定代表出现了故障。 CLUSTER_RECOVERED 集群完全重启时，所有分片都被标记为未分配状态，因此在集群...
Elasticsearch 索引red问题修复
ArchitecTang的博客
08-26 1823
在一次服务器因故宕机的事故中，Elasticsearch 部分索引状态变为red，通过简单的脚本进行修复
elasticsearch 索引 red 状态恢复 green
alex的博客
06-27 5393
elasticsearch 索引 red 状态恢复 green
ElasticSearch集群宕机，重启后某个索引状态为red
u010483897的博客
07-27 1456
问题现象： es集群宕机重启后，某个索引不能正常使用； 问题原因： 因服务器磁盘爆了，导致es集群宕机； 解决方案： 1- 查看所有分片状态 curl -X GET "http://ip:port/_cat/shards" 应该可以看出不能使用的那个索引，主备分片全部处于unsigend状态。 2-直接在kibana执行下面指令，对集群中分配失败的索引进行重新分配 POST /_cluster/reroute?retry_failed=true 3-执行后，过一会执行下这一句看下结.
ES--解决集群健康状态是Red、Yellow的问题
IT利刃出鞘的博客
08-03 2765
本文介绍如何修复ES的非健康状态（黄色或者红色）。
Elasticsearch生产应用（进阶版），不知道怎么提升生产ES集群性能，看这篇就可以了
虚构规律，寰宇笑谈
10-11 1637
Red 和 yellow 是集群运维中常见的问题除了集群故障，一些创建，增加副本登操作，都会导致集群短暂的red 和yellow，所以监控和报警时需要设置一定的延时通过检查节点数，使用ES提供的相关API，找到真正的原因可以指定move 或者reallocate分片。
《ElasticSearch技术解析与实战-朱林》
welcome to 一点点 home
03-11 2517
《第一章：ElasticSearch》 ElasticSearch 简介： ElasticSearch 是一个实时的分布式搜索和分析引擎，它可以帮助你用非常短的时间去处理大规模数据。ElasticSearch 是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于Restful web 接口，ElasticSearch 是用java 开发的，并作为Apache 许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使
ElasticSearch中的某个index的状态显示为red的问题、index显示Unassigned Shards
weixin_47345703的博客
10-13 198
https://blog.youkuaiyun.com/tototuzuoquan/article/details/117331093
Elasticsearch的Snapshot and Restore（快照备份与恢复）
大叶子不小的博客
12-08 2681
无论使用哪种存储数据的软件，定期备份数据都是很重要的。Elasticsearch 副本提供了高可靠性；它们让你可以容忍少量的节点丢失而不会中断服务。但是，副本并不提供对灾难性故障的保护。对这种情况，你需要的是对集群真正的备份——在某些东西确实出问题的时候有一个完整的拷贝。需要注意的是Elasticsearch并不支持直接拷贝集群data目录、备份服务器的方式来备份、升级群集，这样做会导致数据损坏、无法恢复数据。
关于elasticsearch 索引状态red问题排查
qq_39378795的博客
05-28 6277
在kibana上看到索引状态为red 通过查阅相关文档发现，red状态为改索引未分配到任一节点，yellow为分配到单一节点。 所以想着为这个索引分配节点，通过以下命令分配节点。 POST /_cluster/reroute { "commands":[ { "allocate_stale_primary":{ "index":"index_name". "shard":0, "node":"targetn_node", "accept_data_loss":
elasticsearch的status一直是red的解决方案
weixin_43365615的博客
01-14 4258
1、使用curl -XGET 'http://192.168.88.2:9200/_cluster/health?pretty'查看索引的状态发现： { "cluster_name" : "my-application", "status" : "red", "timed_out" : false, "number_of_nodes" : 1, "number_of_data_nodes" : 0, "active_primary_shards" : 0, "active_sha
elasticsearch 请求超时index red状态和index read_only_allow_delete问题分析
weixin_42106137的博客
01-22 131
注意： watermark setting可以通过update-api动态修改，默认es每隔30s会收集各个节点磁盘的使用情况，可以cluster.info.update.interval来设置时间间隔。注：es根据磁盘使用情况来分配shard，默认设置是开启的，也可以通过api关闭：cluster.routing.allocation.disk.threshold_enabled: false。超时的原因比较复杂，可能的原因有：索引太多、分片太多、集群正在处理的任务较多。获取任务:_cat/tasks?
es 通用操作
天空之城
03-02 341
集群健康检查 curl http://localhost:9200/_cluster/health?pretty { "cluster_name" : "xxxxx", "status" : "red", "timed_out" : false, "number_of_nodes" : 3, "number_of_data_nodes" : 3,
Elasticsearch（ES）集群中索引状态red如何处理
喝醉酒的小白
01-03 2242
Elasticsearch（ES）集群中索引状态为表示该索引中至少有一个主分片不可用（无法分配或丢失），这可能导致数据丢失或服务不可用。以下是排查索引状态为通过以下命令确认哪些索引的状态为。
干货 | Elasticsearch 集群健康值红色终极解决方案
热门推荐
铭毅天下Elasticsearch
11-04 4万+
题记 Elasticsearch当清理缓存（ echo 3 > /proc/sys/vm/drop_caches ）的时候，出现 如下集群健康值：red，红色预警状态，同时部分分片都成为灰色。 查看Elasticsearch启动日志会发现如下： 集群服务超时连接的情况。 bserver: timeout notification from cluster service. ...
打开kibana 出现ui settings Elasticsearch plugin is red及以下爆红错误的解决方案。
solar_xie的博客
02-24 5296
1.版本不兼容导致，将kibana版本修改成与elasticsearch版本一致即可 2.kibana的指链接的ES地址即ELASTICSEARCH_URL配置错误，建议删掉kibana容器，重新按再拿个kibana容器，在安装时即可配置es连接地址。 1.查询kibana容器id docker ps 2.删除原有kibana容器,以下的a6103b是查询出的容器id，将其替换成自己的即可 docker rm -f a6103b 3.重新下载kibana并配置es地址，将以下地址替..
Elasticsearch快照恢复数据状态为red
02-16
### 解决 Elasticsearch 快照恢复后集群状态为 Red 的方案 当执行快照恢复操作之后，如果发现 Elasticsearch 集群的状态变为红色 (Red)，这通常意味着某些索引分片未能成功分配到节点上。这种情况可能由多种因素引起。 #### 可能的原因分析 1. **磁盘空间不足** 如果目标节点上的可用存储容量不足以容纳正在尝试加载的数据，则可能导致此问题的发生[^1]。 2. **数据分布不均** 当集群中的各个节点间存在显著差异时——比如硬件配置不同步或是网络连接质量参差不齐——可能会造成部分分片无法正常迁移至预期位置。 3. **元数据冲突** 在极少数情况下，旧有残留的元数据记录也可能干扰新版本快照的应用过程，进而影响整个系统的稳定性与一致性。 4. **副本设置过高** 若设置了过多的副本来提高冗余度，在资源有限的情况下反而会造成压力过大而难以完成全部任务的要求。 #### 推荐解决方案 针对上述提到的各种可能性，建议采取如下措施来排查并解决问题： - **检查日志信息**：查看 `elasticsearch` 日志文件以获取更详细的错误提示；这些线索有助于定位具体失败原因所在的位置。 - **验证磁盘状况**：确认所有参与运算的服务端设备都拥有足够的剩余空间用于承载新增加的工作负载量级，并适当调整相应参数如 `cluster.routing.allocation.disk.watermark.*` 来优化决策逻辑。 - **均衡工作负荷**：通过重新规划架构设计或者引入额外计算单元的方式实现更加合理的分工协作模式，从而减少因局部过载所引发的一系列连锁反应风险事件发生的概率。 - **清理历史遗留物项**：移除任何不再必要的陈旧组件及其关联属性定义等内容，确保当前环境处于最佳运行条件之下再继续后续步骤的操作流程处理动作。 - **降低复制因子**：临时性地下调 index.number_of_replicas 参数值直至最低限度（即0），以便于加快同步速度的同时也减轻整体负担程度，待恢复正常后再逐步上调回初始设定水平线以上范围之内。 ```json PUT /_all/_settings { "index": { "number_of_replicas": 0 } } ```
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值