⚠️ 截止目前最新的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数量，持续升高的情况需要进行关注。
这个问题发生的时候，必须找到数据目录下，存在大量translog文件的索引目录(可能会有上万的translog文件)，找到对应目录的索引名称，然后关闭复制片，待translog清理完毕以后，再打开复制片重新复制。
该问题有人已经在GITHUB上汇报如下:
issues/29097
BUG已经被确认，修复代码已经进入6.2.4 pull/29125 ，但该版本还未正式release。
准备上6版本的同学先请稍待新版本发布以后再行动，已经在6版本的同学，注意监控结点的FD数量，持续升高的情况需要进行关注。
[尊重社区原创，转载请保留或注明出处]
本文地址：http://elasticsearch.cn/article/573
本文地址：http://elasticsearch.cn/article/573
16 个评论
@kennywu76 ,你们现在生产已经升到6.2.3了么
有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
