我感觉这个bug和6.x引入的translog retention策略有关系。  
 
为了加速热索引的recovery， 6.x开始对于translog不再是flush以后立即清除，而是保留一定的大小，由以下两个参数控制：

index.translog.retention.size    #默认512mb
index.translog.retention.age    #默认12h

 
保留一定量的translog的目的，是为了出现热索引recovery情况的时候，借助保留的translog和seqno (也是6.x引入的，记录已经提交到lucene的文档序列号)， 可以免去跨结点的shard文件拷贝消耗，直接从translog快速恢复数据。
 
由于保留了一定时间的translog不清除，那么判断是否需要flush，以及flush的时候清除哪些文件的的条件就复杂了一些。需要比较哪些translog里的doc已经全部提交，哪些还未提交或者部分提交。 这些判断是通过比较translog里保留的seqno和local checkpoint记录的seqno来做出的。
 
但是这个特性实现上看起来有些bug，在一些极端场景造成了flush死循环。 官方尝试在6.1.3/6.2.0修复这个问题(  pull/28350  )， 但问题并未真正解决。  
 
在用户报告问题以后，官方又发布了6.2.4 ( pull/29125 )， 经过我们生产集群的验证，升级到6.2.4以后再未遇到类似的问题。