今天elasticsearch两个节点服务器异常掉电重启,遇到translog损坏的异常,将修复的过程记录下来。
单机数据量有2亿+,一个index,20+个字段,使用bulk不停的写数据,bulk.size=5000,此时机器意外断电宕机。
机器修复后重启ES,出现translogCorruptedException异常:
[2018-04-18 16:29:25,950][WARN ][indices.cluster ] [elasticsearch_43_ssd] [ocslog-2018.04.18][0] failed to start shard
org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [ocslog-2018.04.18][0] failed to recover shard
at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:287)
at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:132)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.elasticsearch.index.translog.TranslogCorruptedException: translog corruption while reading from stream
at org.elasticsearch.index.translog.ChecksummedTranslogStream.read(ChecksummedTranslogStream.java:70)
at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:257)
... 4 more
Caused by: java.io.EOFException
at org.elasticsearch.common.io.stream.InputStreamStreamInput.readBytes(InputStreamStreamInput.java:53)
at org.elasticsearch.index.translog.BufferedChecksumStreamInput.readBytes(BufferedChecksumStreamInput.java:55)
at org.elasticsearch.common.io.stream.StreamInput.readBytesReference(StreamInput.java:86)
at org.elasticsearch.common.io.stream.StreamInput.readBytesReference(StreamInput.java:74)
at org.elasticsearch.index.translog.Translog$Index.readFrom(Translog.java:495)
at org.elasticsearch.index.translog.ChecksummedTranslogStream.read(ChecksummedTranslogStream.java:68)
... 5 more
[2018-04-18 16:29:25,959][WARN ][cluster.action.shard ] [elasticsearch_43_ssd] [ocslog-2018.04.18][0] sending failed shard for [ocslog-2018.04.18][0], node[hROI0lMDQvqFNa2pcdlrGg], [P], s[INITIALIZING], indexUUID [opNRuZb0QS-UseDQlAadfA], reason [Failed to start shard, message [IndexShardGatewayRecoveryException[[ocslog-2018.04.18][0] failed to recover shard]; nested: TranslogCorruptedException[translog corruption while reading from stream]; nested: EOFException; ]]
[2018-04-18 16:29:25,959][WARN ][cluster.action.shard ] [elasticsearch_43_ssd] [ocslog-2018.04.18][0] received shard failed for [ocslog-2018.04.18][0], node[hROI0lMDQvqFNa2pcdlrGg], [P], s[INITIALIZING], indexUUID [opNRuZb0QS-UseDQlAadfA], reason [Failed to start shard, message [IndexShardGatewayRecoveryException[[ocslog-2018.04.18][0] failed to recover shard]; nested: TranslogCorruptedException[translog corruption while reading from stream]; nested: EOFException; ]]
[2018-04-18 16:29:26,304][WARN ][cluster.action.shard ] [elasticsearch_43_ssd] [ocslog-2018.04.18][0] received shard failed for [ocslog-2018.04.18][0], node[hROI0lMDQvqFNa2pcdlrGg], [P], s[INITIALIZING], indexUUID [opNRuZb0QS-UseDQlAadfA], reason [master [elasticsearch_43_ssd][hROI0lMDQvqFNa2pcdlrGg][ocsbak][inet[/192.168.0.43:9300]]{tag=hot, max_local_storage_nodes=1, master=true} marked shard as initializing, but shard is marked as failed, resend shard failure]
[2018-04-18 16:29:26,624][WARN ][cluster.action.shard ] [elasticsearch_43_ssd] [ocslog-2018.04.18][0] received shard failed for [ocslog-2018.04.18][0], node[hROI0lMDQvqFNa2pcdlrGg], [P], s[INITIALIZING], indexUUID [opNRuZb0QS-UseDQlAadfA], reason [master [elasticsearch_43_ssd][hROI0lMDQvqFNa2pcdlrGg][ocsbak][inet[/192.168.0.43:9300]]{tag=hot, max_local_storage_nodes=1, master=true} marked shard as initializing, but shard is marked as failed, resend shard failure]
[2018-04-18 16:29:27,174][WARN ][cluster.action.shard ] [elasticsearch_43_ssd] [ocslog-2018.04.18][0] received shard failed for [ocslog-2018.04.18][0], node[hROI0lMDQvqFNa2pcdlrGg], [P], s[INITIALIZING], indexUUID [opNRuZb0QS-UseDQlAadfA], reason [master [elasticsearch_43_ssd][hROI0lMDQvqFNa2pcdlrGg][ocsbak][inet[/192.168.0.43:9300]]{tag=hot, max_local_storage_nodes=1, master=true} marked shard as initializing, but shard is marked as failed, resend shard failure]
提示:ocslog-2018.04.18,主分片失败,有如下错误信息:
TranslogCorruptedException[translog corruption while reading from stream]
看样子是异常掉电导致 Translog 日志异常了
-
先关闭集群
-
尝试清除 ocslog-2018.04.18 索引对应的 Translog 恢复日志,找到 translog 文件所在目录:
/home/local/elasticsearch/data/elasticsearch_ocs/nodes/0/indices/ocslog-2018.04.18/0/translog
下面有一个 translog*.recorving 的文件,将其备份并删除
-
重启集群后问题恢复
ES 的translog中包含 对ES所有的所有更改,是数据备份和恢复的重要组件。
如果在写translog时发生宕机事故,translog写入流程没有正常的结束,translog文件结尾没有正确的结束符号,导致eof Exception。
详细参考:
https://blog.csdn.net/jiao_fuyou/article/details/79997292
ElasticSearch6.3.2,三
节点
集群
Ubuntu16.04
一个名为user的索引,索引配置为:3 primary
shard
,每个primary
shard
2个replica
正常情况下,各个分片的分布如下:
可见,user 索引的三个分片平均分布在各台机器上,可以完全容忍一台机器宕机,而不丢失任何数...
1台master
节点
,4台data
节点
,9个
shard
s
一台data
节点
宕机,
导致
5个分片处于unassigned状态,集群状态变为red,无法自动rerouting
解决步骤:
1.查看所有
节点
的日志信息,通过日志,我们发现master
节点
中出现了警告信息,通知宕机
节点
的磁盘利用率超过了90%,这也是
导致
节点
宕机,集群出现unassigned的原因。
启动
初始化时间长
修改
es
配置,
重启
集群成本巨大。
ES
集群已有25T数据,27个
节点
,24个数据
节点
(热盘12和hot
节点
,慢盘12个stale
节点
,3个mater
节点
),数据
节点
的
启动
,加入集群后需要初始化全部索引,这个过程过程很慢。全部
重启
一次可能要一天,非常耗时。
重启
后经常遇到少量索引一直处于unassigned状态,
导致
集群一直是red状态。
有时调整配置,希望能快
然后
重启
Elasticsearch。
[root@localhost nod
es
]# find . -name *recovering
./0/indic
es
/kstore/2/translog/translog-1610419642255.recovering
./1/indic
es
/kstore/4/translog/translog-1610419642197.recovering
./1/indic
es
/kstore/2/translog/translog-1.
在使用
ES
的过程中遇到以下
问题
:
[2015-01-06 16:12:34,061][WARN ][indic
es
.cluster ] [node_141] [ips][4] failed to start
shard
org.elasticsearch.index.gateway.Index
Shard
GatewayRecoveryException: [ips][4] fai
启动
服务之后总是无缘无故自己挂掉,查看
es
的日志 在
es
安装目录下的logs下查看报错内容
发现报错为OOM,调大最大可占用内存 在config目录下的jvm.options中-Xmx和-Xms的大小
注意:
不能
超过
服务器
50%
2.
启动
程序读取
es
数据,程序报错,内容为没有可用的
es
节点
因为程序报错为没有可用的
es
节点
,所以我第一时...
对于datanode可以在master中配置,然后在maste
启动
的时候,一并去
启动
这些
节点
。
对于死掉的
节点
,也可以通过以下命令
启动
。
重启
挂掉的
节点
进入到 挂掉的机器
bin/hadoop-daemon.sh start datanode //
启动
数据
节点
bin/hadoop-daemon.sh start tasktracker //
启动
任务管理器
此时再在mas
Red Cluster!
摘自:http://blog.kiyanpro.com/2016/03/06/elasticsearch/reroute-unassigned-
shard
s/
There are 3 cluster stat
es
:
green: All primary and replica
shard
s are active
yellow: All primary...
直接
重启
节点
可能会
导致
集群出现
异常
。比如,对于 Swarm Mode 集群内的 Manager
节点
,如果 Manager 健康
节点
数小于 2,则可能会
导致
集群无法自愈,最终
导致
集群不可用。本文结合阿里云历史案例经验,说明了在对容器服务进行主动运维等场景下,需要
重启
节点
时的操作最佳实践。
检查业务高可用配置
在
重启
容器服务
节点
前,建议先检查或修正如下业务...
MySQL分区之RANGE分区
WgRui: