Elasticsearch索引的分片分配Recovery使用讲解

来自:网络
时间:2022-04-20
阅读:
目录

什么是recovery?

在elasticsearch中,recovery指的是一个索引的分片分配到另外一个节点的过程,一般在快照恢复、索引复制分片的变更、节点故障或重启时发生,由于master节点保存整个集群相关的状态信息,因此可以判断哪些分片需要再分配及分配到哪个节点,例如:

  • 如果某个主分片在,而复制分片所在的节点挂掉了,那么master需要另行选择一个可用节点,将这个主分片的复制分片分配到可用节点上,然后进行主从分片的数据复制。
    如果某个主分片所在的节点挂掉了,复制分片还在,那么master会主导将复制分片升级为主分片,然后再做主从分片数据复制。
  • 如果某个分片的主副分片都挂掉了,则暂时无法恢复,而是要等持有相关数据的节点重新加入集群后,master才能主持数据恢复相关操作。

但是,recovery过程要消耗额外的资源,CPU、内存、节点间的网络带宽等。可能导致集群的服务性能下降,甚至部分功能暂时无法使用,所以,有必要了解在recovery的过程和其相关的配置,来减少不必要的消耗和问题。

减少集群full restart造成的数据来回拷贝

有时候,可能会遇到es集群整体重启的情况,比如硬件升级、不可抗力的意外等,那么再次重启集群会带来一个问题:某些节点优先起来,并优先选举出了主节点,有了主节点,该主节点会立刻主持recovery的过程。

但此时,这个集群数据还不完整(还有其他的节点没有起来),例如A节点的主分片对应的复制分片所在的B节点还没起来,但主节点会将A节点的几个没有复制分片的主分片重新拷贝到可用的C节点上。而当B节点成功起来了,自检时发现在自己节点存储的A节点主分片对应的复制分片已经在C节点上出现了,就会直接删除自己节点中“失效”的数据(A节点的那几个复制分片),这种情况很可能频繁出现在有多个节点的集群中。

而当整个集群恢复后,其各个节点的数据分布,显然是不均衡的(先启动的节点把数据恢复了,后起来的节点内删除了无效的数据),这时,master就会触发Rebalance的过程,将数据在各个节点之间挪动,这个过程又消耗了大量的网络流量。所以,我们需要合理的设置recovery相关参数来优化recovery过程。

  • 在集群启动过程中,一旦有了多少个节点成功启动,就执行recovery过程,这个命令将master节点(有master资格的节点)和data节点都算在内。
gateway.expected_nodes: 3
  • 有几个master节点启动成功,就执行recovery的过程。
gateway.expected_master_nodes: 3
  • 有几个data节点启动成功,就执行recovery的过程。
gateway.expected_data_nodes: 3

当集群在期待的节点数条件满足之前,recovery过程会等待gateway.recover_after_time指定的时间,一旦等待超时,则会根据以下条件判断是否执行recovery的过程:

gateway.recover_after_nodes: 3    # 3个节点(master和data节点都算)启动成功
gateway.recover_after_master_nodes: 3  # 3个有master资格的节点启动成功
gateway.recover_after_data_nodes: 3   # 3个有data资格的节点启动成功

上面三个配置满足一个就会执行recovery的过程。
如果有以下配置的集群:

gateway.expected_data_nodes: 10
gateway.recover_after_time: 5m
gateway.recover_after_data_nodes: 8

此时的集群在5分钟内,有10个data节点都加入集群,或者5分钟后有8个以上的data节点加入集群,都会启动recovery的过程。

减少主副本之间的数据复制

如果不是full restart,而是重启单个节点,也会造成不同节点之间来复制,为了避免这个问题,可以在重启之前,关闭集群的shard allocation。

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable":"none"
  }
}

当节点重启后,再重新打开:

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable":"all"
  }
}

这样,节点重启后,尽可能的从本节点直接恢复数据。但是在es1.6版本之前,既使做了以上措施,仍然会出现大量主副分片之间的数据拷贝,从面上看,这点让人很不理解,主副分片数据是完全一致的,在节点重启后,直接从本节点的副本重恢复数据就好了呀,为什么还要再从主分片再复制一遍呢?原因是在于recovery是简单的对比主副分片的segment file(分段文件)来判断哪些数据一致是可以本地恢复,哪些不一致的需要重新拷贝的。而不同节点的segment file是完全独立运行的,这可能导致主副本merge的深度不完全一致,从而造成即使文档集完全一样,而产生的segment file却不完全一样。

为了解决这个问题,在es1.6版本之后,加入了synced flush(同步刷新)新特性,对于5分钟没有更新过的shard,会自动synced flush一下,其实就是为对应的shard加入一个synced flush id,这样在节点重启后,先对比主副shard的synced flush id,就可以知道两个shard是否完全相同,避免了不必要的segment file拷贝。

需要注意的是synced flush只对冷索引有效,对于热索引(5分钟内有更新的索引)无效,如果重启的节点包含有热索引,那还是免不了大量的拷贝。如果要重启一个包含大量热索引的节点,可以按照以下步骤执行重启过程,可以让recovery过程瞬间完成:

  • 暂停数据写入
  • 关闭集群的shard allocation
  • 手动执行 POST /_flush/synced
  • 重启节点
  • 重新开启集群的shard allocation
  • 等待recovery完成,当集群的health status是green后
  • 重新开启数据写入

特大热索引为何恢复慢

对于冷索引,由于数据不再更新(对于elasticsearch来说,5分钟,很久了),利用synced flush可以快速的从本地恢复数据,而对于热索引,特别是shard很大的热索引,除了synced flush派不上用场,从而需要大量跨节点拷贝segment file以外,translog recovery可能是导致慢的更重要的原因。
我们来研究下这个translog recovery是什么鬼!
当节点重启后,从主分片恢复数据到复制分片需要经历3个阶段:

  • 第一阶段,对于主分片上的segment file做一个快照,然后拷贝到复制分片所在的节点,在数据拷贝期间,不会阻塞索引请求,新增的索引操作会记录到translog中(理解为于临时文件)。
  • 第二阶段,对于translog做一个快照,此快照包含第一阶段新增的索引请求,然后重放快照里的索引操作,这个阶段仍然不会阻塞索引请求,新增索引操作记录到translog中。
  • 第三阶段,为了能达到主副分片完全同步,阻塞新索引请求,然后重放上一阶段新增的translog操作。

由此可见,在recovery过程完成之前,translog是不能被清除掉的。如果shard比较大,第一阶段会耗时很长,会导致此阶段产生的translog很大,重放translog要比简单的文件拷贝耗时更长,因此第二阶段的translog耗时也显著的增加了。等到了第三阶段,需要重放的translog可能会比第二阶段更多。要命的是,第三阶段是会阻塞新索引(写入)请求的,在对写入实时性要求很高的场合,这就会导致性能下降,非常影响用户体验。因此,要加快特大热索引恢复速度,最好是参照上一节中的方式:

  • 暂停数据写入。
  • 手动synced flush。
  • 等待数据恢复完成后。
  • 重新恢复数据写入。

这样就会把数据延迟影响降到最低。

欢迎斧正,that's all see also:[本文主要参考:Elasticsearch Recovery详解]

(https://blog.csdn.net/u012450329/article/details/52881045) | [cat recovery]

(https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-recovery.html) | [Indices Recovery]

(https://www.elastic.co/guide/en/elasticsearch/reference/current/recovery.html)

以上就是Elasticsearch索引的分片分配Recovery使用讲解的详细内容,更多关于Elasticsearch索引的分片分配Recovery 的资料请关注其它相关文章!

返回顶部
顶部