【问题标题】:How to tune translog retention for small indices?如何调整小索引的 translog 保留?
【发布时间】:2019-05-13 08:23:08
【问题描述】:

目前正在开发电子商务解决方案,我们正在使用 Elasticsearch 6.x 来启用对产品的全文搜索。

我们有 88 个索引,每个索引都有一个大约 50mb 的 primary.store.size。每个主节点都有一个副本。我们经常通过使用固定 _id 的批量索引来重新生成这些索引。正因为如此,translog 正在增长。

我的每个索引都与通过 _cat/indices 提供的这些数据非常相似:

    index      pri rep docs.count  docs.deleted store.size  pri.store.size
    myindex_1   1   1     105533            0     79.4mb         39.7mb

对于同一个索引,这里是_cat/recovery数据:

index    shard  time  type        stage snapshot files files_recovered files_percent files_total bytes   bytes_recovered bytes_percent bytes_total translog_ops translog_ops_recovered translog_ops_percent
myindex_1 0     14ms  empty_store done  n/a      0     0               0.0%          0           0       0               0.0%          0           0            0                      100.0%
myindex_1 0     22ms  peer        done  n/a      1     1               100.0%        1           233     233             100.0%        233         0            0                      100.0%

对于同一个索引,这里是_cat/shards数据:

index      shard prirep state     docs  store 
myindex_1  0     p      STARTED 105533 39.7mb 
myindex_1  0     r      STARTED 105533 39.7mb 

在其默认配置中,translog 保留大小为 512mb,保留期限为 12h。根据文档,translog 现在可以保存更长时间,以实现更快的分片恢复机制。

鉴于我们的索引大小与 translog 大小相比非常小,我可以安全地调整 translog 保留期限或保留大小吗?还是我会更好地增加存储空间以考虑默认的 translog 属性?

【问题讨论】:

  • 您能否提供更多与您的索引大小、分片数量和事务日志大小相关的信息? GET _cat/indices?v + GET _cat/shards?v + GET _cat/recovery?v
  • 您好,感谢您的回答,我提供了有关我们索引数据的更多信息。然而,我们不能抽象出我的服务器配置的这个“问题”吗?我很想知道回退到以前的恢复系统是否不能比使用依赖撤消/重做日志的系统更快,因为索引传输日志可能大于我的索引大小。我知道对非常大的索引使用 translog 性能更高,但对于我的用例,我真的不知道。

标签: elasticsearch


【解决方案1】:

保留设置控制传输日志文件的数量和应保留多长时间,以便在恢复期间刷新离线副本。

您在 translog 文件中保留的信息越多,成功恢复的机会就越大,但大文件将需要更多的服务器资源,并且它们的处理时间会更长。所以,你必须在这里保持良好的平衡。

如果您遇到高吞吐量工作负载,保留大小的默认设置为 512 MB 是不够的,因此您可以放心地将其增加到 1024 MB。保留期限也可以更改,并且可能会导致您增加磁盘存储空间,因此一旦更新了这两个设置,请密切关注可用磁盘空间,并根据需求计划所需的磁盘存储升级。

【讨论】:

  • 感谢您的回答。尽管如此,根据一篇文章elastic.co/fr/blog/elasticsearch-sequence-ids-6-0,如果我对 6.x 之前的版本没有错的话,Elasticsearch 分片恢复机制依赖于 lucene 段副本。对于 6.x 版本,如果 translog 太旧,我们应该使用该策略。鉴于索引存储的大小在 translog 大小之前非常小,我是否可以冒险更改保留大小,因为我知道复制 Lucene 段应该很快(可能比使用非常大的 translog 更快)。
  • 文件复制通常是一项昂贵的操作,只有通过测试两种恢复方法才能找出哪种方法更快:translog 与旧的基于文件的技术。当你有相当大的translog时,试着模拟一个失败,然后以两种方式恢复你失败的副本。接下来,您可以轻松衡量您所花费的努力并做出最终决定重新复制方法。我投票支持 translog 的快速恢复,除非您遇到硬件崩溃。
猜你喜欢
  • 1970-01-01
  • 2013-02-05
  • 2016-06-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-05-11
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多