【发布时间】: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