elasticsearch 集群启动流程

elasticsearch 集群启动流程

es 的集群启动过程要经历选举主节点、主分片、数据恢复等重要阶段,理解其中原理和细节,对于解决或避免集群维护过程中可能遇到的脑裂,无主,恢复慢,丢数据等问题有重要作用。本文基于es 5.5.3版本,以通俗的语言描述流程中的原理和机制。


基于版本:5.5.3

相对于节点启动流程,我们通常更关注集群启动流程,这次不研究细节,说说原理和机制。

集群启动整体流程:

选举主节点

选主是对Bully算法的改进,主要思路是对节点 ID 排序,取最大值做 master,每个节点都运行这个流程。由此产生三个制约条件:

  1. 参选人数需要过半,达到quorum后就选出了临时的主。为什么是临时的?每个节点运行排序取最大值的算法,结果不一定相同。举个栗子,集群有5台主机,节点 ID 分别是:1,2,3,4,5.当产生网络分区或者节点启动速度差异较大,节点1 看到的节点列表是:1,2,3,4,选出4;节点2看到的节点列表:2,3,4,5,选出5。结果就不一致了由此产生第二条限制。
  2. 得票数须过半。某节点被选为主,须判断加入他的节点数过半,才确认 master 身份。解决第一个问题。
  3. master 节点,当探测到节点离开事件,须判断当前节点数是否过半。如果不到quorum,则放弃 master 身份,重新加入集群。如果不这么做,设想以下情况:假设10台机器组成的集群产生网络分区,3台一组,7台一组,产生分区前, Master位于3台中的一个,此时7台1组的节点会重新并成功选取 Master,产生双主,俗称脑裂。

选举集群元信息

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

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

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

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

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

allocation 过程

选举 shard 级元信息,构建路由表,是在 allocation 模块完成的。初始阶段,所有的 shard 都处于UNASSIGNED状态。此时,首先要做的是分配主分片。

选主分片

好,现在看某个主分片:[website][0]是怎么分配的。所有的分配工作都是 Master 来做的,此时,Master 不知道主分片在哪,他向集群的所有节点询问:大家把[website][0]分片的元信息发给我。然后,Master 等待所有的请求返回回来,正常情况下他有就有了这个 shard 的信息,然后根据某种策略选一个分片做主。是不是很 low?这种询问量=shard 数*节点数。

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

如果集群设置了:

只要磁盘可分配主分片的 shard,会强制分配主分片。因此,在设置了上述选项的情况下,集群重启后的状态为 yellow,而非 red

选副分片

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

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

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

index recovery

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

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

主分片 recovery

对于主分片来说,这些未刷盘数据可以从 translog 恢复,每次刷盘完毕,translog 都会被清空,因此把 translog 中的数据全部重放,建立 lucene 索引,如此完成主分片的 recovery。

副分片 recovery

副分片需要恢复成与主分片一致,同时,恢复期间允许新的索引操作。因此在主分片所在节点,调用 lucene 接口把 shard 做快照。恢复进入:

  • 第一阶段:把 shard 数据拷贝到副本节点。如果主副两 shard 有相同的 syncid 且 doc 数相同,则跳过这个阶段。在第一阶段完毕前,会向副分片阶段发送告知对方启动 engine,在第二阶段开始之前,副分片就可以正常处理写请求了
  • 第二阶段:对 translog 做快照,这个快照里包含从第一个节点开始的新增索引.

假设恢复期间一直有新增写操作,这两个阶段中需要重点关注几个问题。

分片完整性:
如何做到副分片不丢数据?第二阶段的 translog 快照包括第一阶段所有的新增操作。那么第一阶段执行期间如果 lucene commit,清除 translog 怎么办?在 es2.0之前,是阻止了刷新操作,以此让 translog 都保留下来。从2.0开始,为了避免这种做法产生过大的 translog,translog 模块被修改为支持多个文件,同时引入 translog.view 的概念,创建 view 可以获取到后续的所有操作。这样实现了在第一阶段允许 lucene commit。

数据一致性:
在 es2.0之前,副分片有三个阶段,第三阶段会阻塞新的索引操作,传输第二阶段执行期间新增的 translog,这个时间很短。自2.0之后,第三阶段被删除,恢复期间没有任何写阻塞过程。在副分片节点,第一阶段结束后,新增索引操作和 translog 重放操作并发执行。因为时序的关系会出现新老数据交替。那如何实现主副分片一致呢?

假设在第一阶段执行期间,新增写操作要求将 doc A 的内容写为1,第二阶段期间新增索引操作要求写 doc A 的内容为2,副分片先执行了将 doc A 写为2的新增请求,对于从 translog 重复放的写 doc A 为1的请求如何处理?

答案是在写流程中做异常处理,通过版本号来过滤掉过期操作。写操作有三种类型:索引新文档,更新,删除。索引新文档不存在冲突问题,更新和删除操作采用相同的处理机制。每个操作都有一个版本号,这个版本号就是预期 doc 版本,他必须大于当前 lucene 中的 doc 版本号。否则就放弃本次操作。对于更新操作来说,预期版本号是 lucene doc 版本号+1。主分片节点写成功后新数据的版本号会放到写副本的请求中,这个请求中的版本号就是预期版本号。

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

集群启动日志

从日志角度看集群启动过程,部分日志调整到了 info 级别

结束语

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

(转载请注明作者和出处 easyice.cn ,请勿用于任何商业用途)

1 Star2 Stars3 Stars4 Stars5 Stars (5 人打了分, 平均分: 4.00 )
Loading...

发表评论

邮箱地址不会被公开。 必填项已用*标注