performance - 如何加速 Elasticsearch 恢复？

Question

我正在处理由 6B 小文档组成的 ES 集群，这些文档以 6.5K 索引组织，总计 6TB。索引在 7 个服务器之间进行复制和分片。索引占用从几 KB 到几百 GB 不等。

在使用ES之前，我用的是Lucene，同样的文档组织方式。

基于 Lucene 的应用程序的恢复非常迅速。事实上，索引在查询到达时延迟加载，然后缓存 IndexReader，以加快 future 的回复。

现在，使用 Elasticsearch，恢复非常缓慢(几十分钟)。请注意，通常在崩溃之前，所有索引都会打开，并且大多数索引会经常接收要索引的文档。

有没有什么好的模式可以减少ES恢复时间？我也对与索引管理相关的任何事情感兴趣，而不仅仅是对配置感兴趣。例如，我想更快地恢复最重要的索引，然后加载所有其他索引；通过这样做，我可以减少大多数用户的停机时间。

我正在使用以下配置:

#Max number of indices cuncurrently loaded at startup
indices.recovery.concurrent_streams: 80

#Max number of bytes cuncurrently readed at startup for loading the indices
indices.recovery.max_bytes_per_sec: 250mb

#Allow to control specifically the number of initial recoveries of primaries that are allowed per node
cluster.routing.allocation.node_initial_primaries_recoveries: 20

#Max number of indices cuncurrently loaded at startup
cluster.routing.allocation.node_concurrent_recoveries: 80

#the number of streams to open (on a node level) for small files (under 5mb) to recover a shard from a peer shard
indices.recovery.concurrent_small_file_streams: 30

PS:目前我使用的是 ES 2.4.1，但几周后我将使用 ES 5.2。PPS:一个场景可能是停电后恢复。

谢谢!

Answer 1

编辑 要优先恢复某些索引，您可以通过这种方式使用索引的优先级设置:

PUT some_index
{
  "settings": {
    "index.priority": 10
  }
}

具有最高优先级的索引将首先被恢复，否则恢复按索引的创建时间排序，参见this

第二次编辑 要更改副本数，您只需要一个 HTTP 请求:

PUT  index_name/_settings
{
  "index":{
    "number_of_replicas" : "0"
  }
}

---

关于快照恢复，我建议以下几点(有些可能不适用于您的情况):

• 在恢复之前将副本数设置为0，然后将其交换回默认值(减少写入)
• 如果使用旋转磁盘，您可以添加到 elasticsearch.yml 以提高索引速度:index.merge.scheduler.max_thread_count: 1(参见 here)
• 在恢复索引设置之前更新:"refresh_interval": "-1" 然后将其恢复为默认值(参见 the doc )

如果您还不关心搜索，ES5 集群上的以下内容也可以提供帮助:

PUT /_cluster/settings
{
    "transient" : {
        "indices.store.throttle.type" : "none" 
    }
}

下面的几篇文章可能会有所帮助:

• https://www.elastic.co/guide/en/elasticsearch/reference/5.x/tune-for-indexing-speed.html
• https://www.elastic.co/guide/en/elasticsearch/reference/5.x/tune-for-disk-usage.html

一些一般提示:确保您有交换禁用。 ES集群中你的节点分配了多少内存？ (由于 jvms 的一些内存寻址限制问题，您应该使用节点总可用内存的一半，上限为 32 GB)。