• 欢迎来到小爱博客,一个分享互联网IT技术的网站,喜欢就收藏吧!

elasticsearch集群启动原理详解

elasticsearch 小爱 2个月前 (08-08) 49次浏览 已收录 0个评论 扫描二维码

让我们从启动流程开始,先在宏观上看看整个集群是如何启动的,集群状态如何从Red变成Green,不涉及代码,然后分析其他模块的流程。

本书中,集群启动过程指集群完全启重启的启动过程,期间要经历选举主节点、分片分配(主副分片的分配)、索引数据恢复等重要阶段,理解其中原理和细节,对于解决或避免集群维护过程中可能遇到的脑裂、无主、恢复慢、丢数据等问题有重要作用

集群启动的整体流程如下图所示:

在这里插入图片描述

1. 选举主节点

假设有若干个节点正在启动,集群启动的第一件事是从已知的活跃机器列表选择一个作为主节点,选主之后的流程由主节点触发。

ES的选主算法是基于Bully算法的改进,主要思路是对节点ID排序,取ID值最大的节点作为Master,每个节点都运行这个流程。是不是非常简单?选主的目的是确定唯一的主节点,初学者可能认为选举出的主节点应该持有最新的元数据信息,实际上这个问题在实现上被分解为两步:先确定唯一的、大家公认的主节点,再想办法把最新的机器元数据复制到选举出来的主节点上

基于节点ID排序的简单选举算法有三个附加约定条件:

  1. 参选人数需要过半,达到quorum(多数)后选出临时的主

    为什么是临时的?每个节点运行排序取最大值的算法,结果不一定相同。举个例子,集群有5台主机,节点ID分别是1、2、3、4、5。当产生网络分区或节点启动速度差异比较大时,节点1看到的节点列表是1、2、3、4,选出4;节点2看到的节点列表是2、3、4、5,选出5。结果就不一致了,由此产生下面的第二条限制。

  2. 得票数需过半

    某节点被选为主节点,必须判断加入它的节点数过半,才确认Master身份。解决第一个问题。

  3. 当探测到节点离开事件时,必须判断当前节点数是否过半

    如果达不到quorm,则放弃Master身份,重新加入集群。如果不这么做,则设想以下情况:假设5台机器组成的集群产生网络分区,2台一组A,3台一组B。产生分区前,Master位于2台中的A,此时3台一组的节点会重新成功选举Master,产生双主,俗称脑裂

集群并不知道自己有多少个节点,quornum值从配置中读取,我们需要设置配置项:

<code class="prism language-yaml has-numbering"><span class="token key atrule">discovery.zen.minimun_master_nodes</span><span class="token punctuation">:</span> <span class="token number">3</span>
</code>
  • 1

2. 选举集群元信息

被选举出的Master和集群元信息的新旧程度没有关系。因为它的第一个任务是选举元信息让各个节点把各自存储的元信息发过来,根据版本号确定最新的元信息,然后把这个信息广播下去,这个集群的所有节点都有了最新的元信息。

集群的元信息的选举包括两个级别:集群级和索引级不包含shard存储于哪个节点的信息。这种信息以节点磁盘存储的为准,需要上报。为什么呢?因为读写流程是不经过Master的,Master不知道各shard副本直接的数据差异。HDFS也有类似的机制,block信息依赖于DataNode的上报。

为了集群一致性,参与选举的元信息数量需要过半,Master发布集群状态成功的规则也是等待发布成功的节点数过半。

在选举过程中,不接受新节点的加入请求。

集群元信息选举完毕后,Master发布首次集群状态,然后开始选举shard级元信息。

3. shard allocation(分配)过程

选举shard级元信息,构建内容路由表,是在allocation模块完成的。在初始阶段,所有的shard都处于**UNASSIGNED(unassigned 未分配)**状态。ES中通过分配过程决定哪个分片位于哪个节点,重构内容路由表。此时,首先要做的就是分配主分片。

3.1 选主分片

现在看某个主分片【website】【0】是怎么分配的。所有的分配工作都是Master来做的,此时,Master不知道主分片在哪,它向集群的所有节点询问:大家把【website】【0】分片的元信息发我。然后,Master等待所有的请求返回,正常情况下它就有了这个shard的信息,然后根据某种策略选一个分片作为主分片。是不是效率有些低?这种询问量=shard数 * 节点数。所以说我们最好控制shard的总规模别太大。

现在有了shard【website】【0】的分片的多份信息,具体数量取决于副本数设置了多少。现在考虑把哪个分片作为主分片。ES 5.x以下的版本,通过对比shard级元信息的版本号来决定。在多副本的情况下,考虑到如果只有一个shard信息汇报上来,则它一定会被选为主分片,但也许数据不是最新的,版本号比它大的节点还没有启动。在解决这个问题的时候,ES 5.x开始实施一种新的策略:给每个shard都设置一个UUID,然后在集群级的元信息中记录哪个shard是最新的,因为ES是先写主分片,再由主分片节点转发请求去写副本分片,所以主分片所在节点肯定是最新的,如果它转发失败了,则要求Master删除那个节点。所以,从ES 5.x开始,主分片选举过程是通过集群元信息中记录的“最新主分片的列表”来确定主分片的:汇报信息中存在,并且这个列表中也存在

如果集群设置了:

<code class="prism language-yaml has-numbering"><span class="token key atrule">cluster.routing.allocation.enable</span><span class="token punctuation">:</span> none
</code>
  • 1

禁止分配分片,集群仍然会强制分配主分片。因此,在设置了上述选项的情况下,集群重启后的状态为Yellow,而非Red。

3.2 选副分片

主分片选举成功后,从上一个过程汇总的shard信息中选择一个副本最为副分片。如果汇总信息中不存在,则分配一个全新副本。操作依赖于延迟配置项:

<code class="prism language-yaml has-numbering"><span class="token key atrule">indexunassigned.node_left.delayed_timeout</span><span class="token punctuation">:</span> <span class="token number">100000</span>
</code>
  • 1

我们的线上环境中最大的集群有100+节点,掉节点的情况并不罕见,很多时候不能第一时间处理,这个延迟我们一般配置为以天为单位。

最后,allocation过程中允许新启动的节点加入集群。

4. index recovery(索引恢复)

分片分配成功后进入recovery流程。主分片的recovery不会等待其副本分片分配成功后才开始recovery。它们是独立的流程,只是副本分片的recovery需要主分片恢复完毕才开始。

为什么需要recovery?对于主分片来说,可能有一些数据没来得及刷盘;对于副本分片来说:一是没有刷盘,二是主分片写完了,副本分片还没有来得及写,主副分片数据不一致。

4.1 主分片recovery

由于每次写操作都会记录事务日志(translog),事务日志中记录了哪种操作,以及相关的数据。因此将最后一次提交(Lucene的一次提交就是一次fsync刷盘过程)之后的translog进行重放,建立Lucene索引,如此完成主分片的recovery。

4.2 副分片recovery

副分片的恢复是比较复杂的,在ES的版本迭代中,副分片恢复策略有过不少调整。

副分片需要恢复成和主分片一致,同时,恢复期间允许新的索引操作。目前的6.0版本中,恢复分成两阶段执行。

  • phase1:在主分片所在节点,获取translog保留锁,从获取保留锁开始,会保留translog不受其刷盘清空的影响。然后调用Lucene接口把shard做快照,这是已经刷磁盘中的分片数据。把这些shard数据复制到副本节点。在phase1完毕前,会向副分片节点发生告知对方启动engine,在phase2开始之前,副本分片就可以正常处理写请求了。
  • phase2:对tanslog做快照,这个快照里包含从phase1开始,到执行translog快照期间的新增索引。将这些translog发送到副本分片所在节点进行重放。

由于需要支持恢复期间的新增写操作(让ES的可用性更强),这两个阶段中需要重点关注以下几个问题:

  1. 分片数据完整性:如何做到副本分片不丢失数据?第二阶段的tanslog快照包括第一阶段所有的新增操作。那么第一阶段执行期间如果发生**“Lucene commit”(将文件系统写缓冲中的数据刷磁盘,并清空translog),清除translog怎么办?在ES 2.0之前,是阻止刷新操作,以此让translog都保留下来。从2.0版本开始,为了避免这种做法产生过大的translog,引入了translog.view的概念,创建view可以获取后续的所有操作。从6.0版本开始,translog.veiw被移除。引入TranslogDetetionPolicy的概念**,它将translog做一个快照来保持translog不被清理。这样实现了在第一阶段允许Lucene Commit
  2. 数据一致性:在ES 2.0之前,副分片恢复过程有三个阶段,第三阶段会阻塞新的索引操作,传输第二阶段期间新增的translog,这个时间很短。自2.0版本之后,第三阶段被删除,恢复期间没有任何写阻塞过程。在副分片节点,重放translog时,phase1和phase2之间的写操作与phase2重放操作之间的时序错误和冲突,通过写流程进行异常处理,对比版本号来来过滤过期操作。

这样,时序上存在错误的操作会被忽略,对于特定的doc,只有最新一次操作生效,保证了主副分片一致。

第一阶段尤其漫长,因为它需要从主分片拉去全量的数据。在ES 6.x中,对第一阶段再次优化:标记每个操作。在正常的写操作中,每次写入成功的操作都分配一个序号,通过对比序号就可以计算出差异范围,在实现方式上,添加了global checkpoint和local checkpoint,主分片负责维护global checkpoint,代表所有分片都已经写入这个序号的位置,local checkpoint代表当前分片已经成功写入的最新位置,恢复时通过对比两个序列号,计算出缺失的数据范围,然后通过translog重放这部分数据,同时translog会为此保留更长的时间。

因此,有两个机会可以跳过副分片恢复的phase1:

  • 基于SequenceNumber,从主分片节点的translog恢复数据
  • 主副分片有相同的syncid且doc数相同,可以跳过phase1。

5. 小结

当一个索引的主分片分配成功后,到此分片的写操作是允许的。当一个索引所有的主分片都分配成功后,该索引变为Yellow。当全部索引的主分片都分配成功后,整个集群变为Yellow。当一个索引全部分配分配成功后,该索引变为Green。当全部索引的索引分片分配成功后,整个集群变为Green。

索引数据恢复是最漫长的过程。当shard总量达到十万级别的时候,6.x之前的版本集群从Red变为Green的时间可能需要小时级。ES 6.X中的副本允许从本地translog恢复是一次重大的改进,避免了ongoing主分片所在的节点拉取全量数据,为恢复过程节约了大量的时间。

量达到十万级别的时候,6.x之前的版本集群从Red变为Green的时间可能需要小时级。ES 6.X中的副本允许从本地translog恢复是一次重大的改进,避免了ongoing主分片所在的节点拉取全量数据,为恢复过程节约了大量的时间。


小爱博客 , 版权所有
转载请注明原文链接:elasticsearch集群启动原理详解
喜欢 (0)
【你的支持, 我的动力】
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址