集群的bootstrap

MetaServer的bootstrap

当一个MetaServer的进程启动时，它会首先根据配置好的zookeeper服务的路径，来检测自己是否能够成为leader。如果是leader, 它会向zookeeper拉去当前集群的所有元数据，包括：

• 有哪些表，以及这些表的各种参数
• 每个表的各个Partition的组成情况，将所有Partition中涉及到的机器求并集，会顺便解析到一个机器列表当MetaServer获取了所有的这些信息后，会构建自己的内存数据结构。特别的，ReplicaServer的集合初始化为2中得到的机器列表。

随后，MetaServer开启FD的模块和负载均衡的模块，MetaServer就启动完成了。

ReplicaServer的bootstrap

当一个ReplicaServer的进程启动时，它会加载自己的所有replica，并且重放所有的WAL。这些replica会被设置为inactive，是不会向外界提供读写服务的。

等加载完成后，ReplicaServer会启动FD模块连接MetaServer。连接成功后会向MetaServer查询自己服务的replica列表，并和自己加载的replica列表相比较并做相应调整：

• 如果本地多出了一部分replica, replica server会将其关闭
• 如果MetaServer多出了一部分replica，请求MetaServer将其移除
• 如果MetaServer和本地都有，按MetaServer所标记的角色进行服务ReplicaServer向MetaServer查询replica列表并做本地调整的这一过程叫ConfigSync。这一过程并不仅限于bootstrap时候会有，而是在集群运行过程中会定期发生的一个任务。

元数据恢复

为了应对集群出现Zookeeper不可用或者Zookeeper丢数据的情况，Pegasus有一个“元数据恢复”的功能。

进行元数据恢复的时候，MetaServer会尝试从ReplicaServer上获取表的元信息，并根据各个Replica的状态重建出PartitionConfiguration。等把这些消息都重建好后，MetaServer会把它们持久化到指定的zookeeper上，然后开始提供服务。

元数据恢复并不能保证把集群的所有信息全部都找回，尤其是和表相关的元信息，ReplicaServer所保留的数据可能是不充分的。所以这一特性只能当成遇到极端情况时的最后一招。在当前Pegasus的实现中，一个已经软删但还没有物理删除的表，经过元数据恢复后，可能会重新变成可读写的表。

如果不是很在意“删除的表被找回”这一点，目前元数据恢复还可以被用于做zookeeper的迁移。