怎么又是你

6.x 复制片恢复引起flush操作死循环的BUG

Elasticsearch | 作者 kennywu76 | 发布于2018年04月13日 | | 阅读数:2135

⚠️ 截止目前最新的ES6版本6.2.3,存在一个复制片恢复过程中可能引起flush死循环的BUG。 我们近期一个ES6.2.2的集群触发了这个bug,导致了一些麻烦。对于写入量很高的集群,这个BUG可能会导致系统的文件描述符被耗尽,结点挂掉,并且重启后依然挂掉的情况。  
 
这个问题发生的时候,必须找到数据目录下,存在大量translog文件的索引目录(可能会有上万的translog文件),找到对应目录的索引名称,然后关闭复制片,待translog清理完毕以后,再打开复制片重新复制。 
 
该问题有人已经在GITHUB上汇报如下:
issues/29097
 
BUG已经被确认,修复代码已经进入6.2.4 pull/29125 ,但该版本还未正式release。
 
准备上6版本的同学先请稍待新版本发布以后再行动,已经在6版本的同学,注意监控结点的FD数量,持续升高的情况需要进行关注。
fds.jpg

 
 

[尊重社区原创,转载请保留或注明出处]
本文地址:http://elasticsearch.cn/article/573


16 个评论

@kennywu76 ,你们现在生产已经升到6.2.3了么
还在6.2.2,在等待6.2.4发布修复这个问题。
有200台机器的超大集群,然后还坚持试用新版本,还能发现bug分享出来,简直太赞了
论踩坑我只服 wood 叔 ?
数据量大了,就容易碰到一些边缘场景。 这次的坑还是给我们带了一些压力,有几个索引受到影响无法写入,来自用户的压力还是比较大的。 用户不管你是否踩到坑了,只会埋怨为何出问题了,影响了他们的工作。?
我这篇文章似乎应该置顶:https://elasticsearch.cn/article/446 ,因为近期发现无论是我们公司内部,还是社区用户,不少对于5.x里keyword和number差异不了解的。 mapping设置不合理以后,引起非常大的查询性能问题。
已添加到帮助中心
非常同意置顶
底层唯一出名的机会就是系统出问题了,@@@
ES6.2.4昨天发布,特别提到修复了这个BUG。 我们测试环境已经升级,观察下来没有问题。 生产环境将开始滚动升级,预计下周全部完成。
@kennywu76 你那篇文章 提到“通过profile查看,发现耗时主要在status字段的build_scorer这个阶段” profile 是个什么工具啊。谢谢
不是什么外部工具,就是ES的Query DSL那你有一个可选的参数 "profile": true, 开启以后,查询结果会打印底层Luene查询执行的步骤和耗时。
6.2.4 还是有问题, 不会出现文件句柄泄漏的问题了,但是会出现 主 副分片磁盘大小不一致的情况,translog 不会正常删除
@Ricky_Lau 6.2.4的确还有问题, 在热索引recovery过程中,translog的确也是一直增加,不会正常删除。最新的6.4.0测试了一下,也是同样的。 在github上开了个issue: https://github.com/elastic/elasticsearch/issues/33229
这个问题除了升级版本之外,有没有什么规避方法呢
对索引定期执行 _flush?force=true,translog 避免达到index.translog.flush_threshold_size

要回复文章请先登录注册