目录
- 启动流程
- 选举主节点
- 选举集群元信息
- allocation 过程
- 主分片
- 副分片
- index recovery
- 主分片 recovery
- 副分片 recovery
- 参考文献
- 目前大部分内容参考自elasticsearch 集群启动流程
流程图
大体流程.png
启动流程
选举主节点
主要思路是对节点 ID 排序，取最大值做 master，每个节点都运行这个流程。由此产生三个制约条件：
- 参选人数需要过半，达到quorum后就选出了临时的主。为什么是临时的？每个节点运行排序取最大值的算法，结果不一定相同。举个栗子，集群有5台主机，节点 ID 分别是：1，2，3，4，5.当产生网络分区或者节点启动速度差异较大，节点1 看到的节点列表是：1，2，3，4，选出4；节点2看到的节点列表：2，3，4，5，选出5。结果就不一致了由此产生第二条限制。
- 得票数须过半。某节点被选为主，须判断加入他的节点数过半，才确认 master 身份。解决第一个问题。
- master 节点，当探测到节点离开事件，须判断当前节点数是否过半。如果不到quorum，则放弃 master 身份，重新加入集群。如果不这么做，有可能导致脑裂。这样的话没有一个节点会接受索引或搜索的请求，让所有的客户端马上发现这个问题。
选举集群元信息
master节点让各节点把其各自存储的元信息发过来，根据版本号确定最新的元信息，然后把这个信息广播下去，这样，集群的所有节点都有了最新的元信息。
- 为了集群一致性，参与选举的元信息数量需要过半，Master 发布集群信息是的成功规则也是过半。
- 在选举过程中，不接受新节点的加入请求。集群元信息选举完毕后，Master 发布首次集群状态，然后开始选举 shard 级元信息。当分配主分片时，主节点检查磁盘中存储的 allocation ID 是否会在集群状态in-sync allocations 集合中出现，只有在这个集合中找到了，此分片才有可能被选为主分片。如果活跃副本中的主分片挂了，in-sync 集合中的活跃分片会被提升为主分片，确保集群的写入可用性不变
allocation 过程
主分片
master向所有节点发起分片请求，Master 等待所有的请求返回回来，正常情况下他有就有了这个 shard 的信息，然后根据某种策略(主节点在选择哪个节点作为主分片方面有很大的灵活性，会将集群均衡和其他约束如分片感知及过滤器考虑在内)选一个分片做主。
- 给每个 shard 都设置一个 UUID，然后在集群级的元信息中记录，哪个 shard 是最新的，因为 es 是先写主分片，再由主分片节点转发请求去写副分片，所以主分片所在节点肯定是最新的，如果他转发失败了，就要求 Master 删除那个节点。
- es5中，主分片是通过集群级元信息中记录的“最新主分片的列表”来确定主分片的：汇报信息中存在，并且这个表中也存在。
选副分片
主分片选举完成后，从上一个过程汇总的 shard 信息中选择一个副本做副分片。如果汇总信息中不存在，分配一个全新副本的操作依赖延迟配置项决定。
index.unassigned.node_left.delayed_timeout
索引恢复
主分片索引恢复(非阻塞)
主分片的 recovery 不会等待其副分片分配成功才开始 recovery，这些未刷盘数据可以从 translog 恢复，每次刷盘完毕，translog 都会被清空，因此把 translog 中的数据全部重放，建立 lucene 索引，如此完成主分片的 recovery。
副分片索引恢复(非阻塞)
副分片需要恢复成与主分片一致，同时，恢复期间允许新的索引操作。因此在主分片所在节点，调用 lucene 接口把 shard 做快照。从主分片恢复到副本分片主要有两个阶段(在主分片节点执行):
- 对比分段信息,如果 syncid 相同且 doc 数量相同,则跳过，否则复制整个分段
- 将当前 translog 做快照,发送所有的 translog operation 到对端节点,不限速
问题关注
- 分片完整性 第一阶段执行期间如果 lucene commit，清除 translog 怎么办,translog 模块被修改为支持多个文件，同时引入 translog.view 的概念，创建 view 可以获取到后续的所有操.
- 数据一致性, 新增过程中同时副本数据在恢复,写流程中做异常处理，通过版本号来过滤掉过期操作
网友评论