行动是治愈恐惧的良药,而犹豫、拖延将不断滋养恐惧。

在Elasticsearch 6.1.3版本中,发现translog文件过多导致异常

Elasticsearch | 作者 zhuo | 发布于2018年05月15日 | 阅读数:5794

我们在压力测试中,通过压力测试,发现translog文件过多,导致OS句柄消耗完毕。搜了社区问题,和这个很类似:https://elasticsearch.cn/question/1343
但我们当前版本已经是6.1.3了,难道在这个版本还存在类似问题?或者是某个地方没配置好?
在指定index的某个shard下,translog文件个数超过13万。
此index的setting信息如下:
 curl -XGET -k -u : "http://127.0.0.1:9200/myindex- ... ot%3B
{
  "myindex-002" : {
    "settings" : {
      "index" : {
        "refresh_interval" : "30s",
        "number_of_shards" : "60",
        "provided_name" : "myindex-002",
        "creation_date" : "1526301558029",
        "number_of_replicas" : "0",
        "uuid" : "iM0QsRb3SXuDpz6ZbBi-wg",
        "version" : {
          "created" : "6010399"
        }
      }
    }
  }
}
  
已邀请:

kennywu76 - Wood

赞同来自: famoss rochy laoyang360

我感觉这个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以后再未遇到类似的问题。

kennywu76 - Wood

赞同来自: zhuo

6.2.4看起来没有修复所有问题,近期发现热索引在recovery过程中,primary和replica的translog文件数量都在缓慢增加,没有正常被删除。 测试了最新的6.4.0依然是同样的问题, 刚刚在Github上开了个issue,等待官方调查: https://github.com/elastic/ela ... 33229
 

rockybean - Elastic Certified Engineer, ElasticStack Fans,公众号:ElasticTalk

赞同来自:

看起来是 bug 了
https://github.com/elastic/ela ... 29097
 
建议用 6.2.4 再测试一下

kennywu76 - Wood

赞同来自:

我们生产遇到过https://elasticsearch.cn/article/573 ,升级到6.2.4以后问题消失。

要回复问题请先登录注册