我正在研究6B小文档的ES群集,这些文档以6.5K索引进行组织,总共6TB。索引在7台服务器之间复制和分片。索引占用量从几KB到几百GB不等。
在使用ES之前,我将Lucene与相同的文档组织一起使用。
基于Lucene的应用程序 的恢复 非常迅速 。实际上,当查询到达时,索引是延迟加载的,然后将IndexReader缓存起来,以加快以后的回复速度。
现在, 使用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:一种情况可能是停电后的恢复。
谢谢!
编辑 要优先确定某些索引的恢复,可以通过以下方式在索引上使用优先级设置:
PUT some_index { "settings": { "index.priority": 10 } }
与最大的优先级指数将首先恢复,否则恢复被索引的创建时间排序的,看到这
第二次编辑 要更改副本数,您只需要一个HTTP请求:
PUT index_name/_settings { "index":{ "number_of_replicas" : "0" } }
关于快照恢复,我建议以下几点(某些情况可能不适用于您的情况):
index.merge.scheduler.max_thread_count: 1
"refresh_interval" : "-1"
如果您还不在乎搜索,则ES5群集上的以下内容也可能会有所帮助:
PUT /_cluster/settings { "transient" : { "indices.store.throttle.type" : "none" } }
以下几篇文章可能会有所帮助:
一些一般性提示:确保已禁用交换功能。ES群集中的节点分配了多少内存?(由于jvm的内存寻址限制问题,您应该使用节点总可用内存的一半,上限为32 GB)。