elasticsearch translog恢复到一定百分比卡住(stuck),导致索引无法恢复
Elasticsearch | 作者 KrisOtk | 发布于2020年07月17日 | 阅读数：5023
es版本: 7.4.1
背景:
生产的某个es集群,3master15data,master 16g,data 30g
某天早上,有同事反馈es集群无法写入了,报了较多sockettimeout;
于是直接登上kibana,先看集群状态,green没有异常,然后上监控大盘看了一下这个es集群的最近24h的内存,磁盘,线程池,发现有单个节点较多拒绝掉和排队的任务,但是这个集群是个新集群,都是ssd,数据量不算很大,应该不存在瓶颈,所以初步怀疑某个数据节点出问题了;
之后登陆了问题节点,查看了一下es的日志信息,发现了部分任务队列满了的日志信息,那就证明这个节点处理能力不行,但是考虑到这批机器都是新的物理机,单机多节点,遂找运维看了一下磁盘有没有异常,结果也是没有异常,每个data节点的硬件信息基本一致,不应该存在较大的处理能力差别;
后面登陆了一下kibana,通过_cat/tasks 查看发现部分search,bulk命令执行时间已经持续了1h以上了,而且task的总量已经超过几万了,而且基本都集中在问题节点上,里面还有一个'internal:indices/flush/synced/pre'的操作,看起来像是同步刷盘的操作,显示执行时间已经超过7h了,应用方没有手动flush的地方,怀疑可能刷盘卡住了,导致后续的查询和写入全部被阻塞起来了;
没办法只能想办法重启问题节点了,把delayed_timeout全部设置成24h后,通过运维平台直接重启了问题节点,
恢复的前半段比较顺利,但是到了33.1%的进度之后再也不上升了,只觉人生黯淡~努力思考,给自己找了个理由,前面flush刷盘卡住了,导致之后的translog全部都是无效的,无法recovery...只能想办法把translog丢了,后面让业务部分重新同步最近的数据了;
努力去官网找干掉translog的方法,7.x有点区别了,找了会文档
执行完提示(生成一个额外的translog,)
几个问题:
1. `internal:indices/flush/synced/pre` 这个action代表的到底是什么操作;
2. 为什么会出现search/bulk操作阻塞一个多少小时的情况,跟flush有没有关联关系;(有没有类似遭遇的小伙伴提供下建议)
3. 有没有遇到过这种问题的大佬提供下处理建议
背景:
生产的某个es集群,3master15data,master 16g,data 30g
某天早上,有同事反馈es集群无法写入了,报了较多sockettimeout;
于是直接登上kibana,先看集群状态,green没有异常,然后上监控大盘看了一下这个es集群的最近24h的内存,磁盘,线程池,发现有单个节点较多拒绝掉和排队的任务,但是这个集群是个新集群,都是ssd,数据量不算很大,应该不存在瓶颈,所以初步怀疑某个数据节点出问题了;
之后登陆了问题节点,查看了一下es的日志信息,发现了部分任务队列满了的日志信息,那就证明这个节点处理能力不行,但是考虑到这批机器都是新的物理机,单机多节点,遂找运维看了一下磁盘有没有异常,结果也是没有异常,每个data节点的硬件信息基本一致,不应该存在较大的处理能力差别;
后面登陆了一下kibana,通过_cat/tasks 查看发现部分search,bulk命令执行时间已经持续了1h以上了,而且task的总量已经超过几万了,而且基本都集中在问题节点上,里面还有一个'internal:indices/flush/synced/pre'的操作,看起来像是同步刷盘的操作,显示执行时间已经超过7h了,应用方没有手动flush的地方,怀疑可能刷盘卡住了,导致后续的查询和写入全部被阻塞起来了;
没办法只能想办法重启问题节点了,把delayed_timeout全部设置成24h后,通过运维平台直接重启了问题节点,
GET _cat/recovery?v&h=i,s,t,ty,st,shost,thost,f,fp,b,bp,to,tor,top&active_only恢复的前半段比较顺利,但是到了33.1%的进度之后再也不上升了,只觉人生黯淡~努力思考,给自己找了个理由,前面flush刷盘卡住了,导致之后的translog全部都是无效的,无法recovery...只能想办法把translog丢了,后面让业务部分重新同步最近的数据了;
努力去官网找干掉translog的方法,7.x有点区别了,找了会文档
bin/elasticsearch-shard remove-corrupted-data --dir /data/es68-data/nodes/0/indices/aqxxxxTiYfUC_w8A/7/translog/ --truncate-clean-translog执行完提示(生成一个额外的translog,)
POST /_cluster/reroute
{
"commands" : [
{
"allocate_stale_primary" : {
"index" : "xxx_index",
"shard" : 7,
"node" : "
aqxxxxTiYfUC_w8A",
"accept_data_loss" : false
}
}
]
}
# 失败的话,把 accept_data_loss 改为true
几个问题:
1. `internal:indices/flush/synced/pre` 这个action代表的到底是什么操作;
2. 为什么会出现search/bulk操作阻塞一个多少小时的情况,跟flush有没有关联关系;(有没有类似遭遇的小伙伴提供下建议)
3. 有没有遇到过这种问题的大佬提供下处理建议
4 个回复
KrisOtk - kris
赞同来自:
打印的堆栈信息中(dump时'_cat/tsaks?v'显示任务`internal:indices/flush/synced/pre`的执行时间为11h),在里面找到了一个blocked的地方,根据`lock: 0x0000000305f692c0`发现主要是两个地方,一个是refresh,一个是flush,上面的refresh线程阻塞等待下面的flush操作释放锁,但是一直都是flush线程一直是runnable状态;
仔细看了下堆栈信息,发现以下信息:
39266.26/3600=10.9072944444;
和11h吻合,那就证明flush这个操作在定期commit的时候一直未执行完成,这个原因没有思考出来
hackerwin7 - aggregator
赞同来自:
luyuncheng
赞同来自:
JiangJibo - 喊我雷锋
赞同来自: