bulk/search请求阻塞 && elasticsarch translog无法恢复,卡在固定百分比

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后,通过运维平台直接重启了问题节点,
GET _cat/recovery?v&h=i,s,t,ty,st,shost,thost,f,fp,b,bp,to,tor,top&active_only
一直查看进度,但是有一个分片恢复进度一直都是0%,关键主分片没问题,副本分配为啥一直没办法恢复呢,想到可能跟上面的flush阻塞有关,只好把'internal:indices/flush/synced/pre'这个任务对应的节点也重启了,然后看到恢复进度逐渐上升,看了一眼translog的大小,1600w,有点多~
恢复的前半段比较顺利,但是到了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. 有没有遇到过这种问题的大佬提供下处理建议