共计 4126 个字符，预计需要花费 11 分钟才能阅读完成。
背景
在单集群部署环境下，OpenMLDB 具备集群内节点级别的高可用能力。但若受到机房断电或者自然灾害等不可抗拒因素，则将造成的机房或大部分节点无奈失常运行的状况，从而引发该集群状态异样，导致在线服务中断。为此，OpenMLDB 提供了一个跨机房容灾计划来解决该问题。在该计划中，用户能够在多个异地机房，别离部署独立的 OpenMLDB 集群，并且将这多套 OpenMLDB 集群设置成为主从复制模式。在这种部署架构下，如果主集群无奈提供服务，用户能够进行主从切换，从而保障业务不中断。
架构
名词定义
- 主集群：能反对读写的集群，并且能够给从集群同步数据。一个主集群能够有多个从集群。
- 从集群：只提供读申请的集群，数据和主集群保持一致；能够在须要的时候切换为主集群；能够部署多个。
- 分片 leader：主分片，接管读写数据。
- 分片 follower：从分片，只承受分片 leader 同步过去的数据，目前不承受客户端的间接写申请。
- offset：本文 offset 特指 OpenMLDB 的 binlog 所保留的数据偏移量，该值越大，阐明保留有更多的陈腐数据。
对于名词的进一步解释能够查看 OpenMLDB 的在线模块架构文档：https://openmldb.ai/docs/zh/m…
指标
- 主集群反对写操作，主从集群都能够反对读操作
- 一个主集群能够有多个从集群作为备份
- 主集群出现意外不可用时可能手动切换，让其中一个从集群晋升为主集群
- 可能主动解决主集群或者从集群外部节点下线不可用（包含 nameserver 和 tablet）的状况
技术计划
主从集群的整体技术架构如下图所示：
主从集群之间的同步信息，次要蕴含数据同步和元信息同步两局部。
初始状态
对于主从集群的初始状态，能够为以下状态之一：
- 主集群和从集群的数据均为空
- 主或从集群不为空，主从集群的表名以及 schema 统一，并且主集群 offset 大于等于从集群的 offset，否则会报错。
元信息同步
元信息同步产生在主从集群的 nameserver 之间。具体的过程如下：
- 建设好主从关系之后，主集群的 nameserver 会向从集群同步主集群的表信息，从集群创立相应的表。留神，主从集群节点数不须要统一，然而每张表的分片数须要保持一致。
- 主集群的 nameserver 每隔一段时间获取从集群的表拓扑信息
数据同步
主从集群之间的数据同步次要通过 binlog 进行，其总体的同步逻辑如下：
- 单集群外部：leader → followers 同步数据
- 主从集群之间：主集群 leader → 从集群 leader 同步数据
下图可视化列举了该同步逻辑和数据流方向。
假如有一个从集群，表为三正本。其具体过程为：主集群分片的 leader 会创立两个 replicator 线程来负责集群外部数据同步，以及 1 个 replicator 线程来负责同步数据到从集群的 leader；从集群的 leader 会创立两个 replicator 线程，别离给从集群外部的 followers 同步数据。
replicator 的具体同步逻辑如下：
- 读取 binlog 并把数据传给 follower
- follower 收到数据，增加到本地 binlog，同时写到本地分片表中
默认状况下，replicator 会一直读取最新的 binlog，如果没有最新数据写入就会期待一小段时间（默认为 100ms），再尝试读取。在同步时效性要求比拟高的场景下，能够批改默认配置（参数 binlog_sync_wait_time，详见文档配置文件），缩小等待时间，然而可能会减少 CPU 的资源耗费。
集群外部主动故障转移
主集群 nameserver 离线
- 主集群中主 namserver 离线之后，主集群中的备 nameserver 就会降级为主 nameserver，更新从集群中表的拓扑信息到新的主 nameserver
- 主集群中备 nameserver 离线，不做任何操作
从集群 nameserver 离线
- 从集群中主 nameserver 离线之后，从集群中的备 nameserver 就会降级为主 nameserver。主集群向从集群获取表拓扑信息时，返回谬误，主集群就会读取从集群的 ZooKeeper 信息，以获取最新的主 nameserver，而后更新表拓扑信息
- 从集群中备 nameserver 离线之后不做任何操作
主集群 tablet 离线
- 主集群内做故障转移，相应的分片选出新的 leader
- 新的 leader 从新和从集群中分片所在的 tablet 建设数据同步关系
从集群 tablet 离线
- 从集群做故障转移，相应的分片选出新的 leader
- 主集群 nameserver 获取从集群表拓扑构造发现曾经有变动，删除对应变动分片的数据同步关系并从新建设
主从集群间手动故障转移
主集群不可用
通过运维命令，晋升从集群为主集群。同时，业务方的写流量和读流量须要切换到以后的新的主集群下，该流量的切换过程须要由业务方零碎来实现。
从集群不可用
业务方原有在从集群上的读流量（如果有），须要全副切换到主集群下。该流量的切换过程须要由业务方零碎来实现。
主从集群搭建实际
集群启动后默认为主集群。通过命令能够将一个集群增加为另一个集群的从集群，或者进行切换、移除。
启动 NS client
主从集群的治理在 NS client 下进行操作，能够应用如下命令启动 NS client。
$ ./bin/openmldb --zk_cluster=172.27.2.52:12200 --zk_root_path=/onebox --role=ns_client其中 zk_cluster 是 ZooKeeper 地址，zk_root_path 是集群在 ZooKeeper 的根门路，role 是启动的角色需指定为 ns_client
对于 NS client 的更多信息，能够参考运维 CLI。
增加从集群
能够应用命令 addrepcluster 来增加一个从集群，其应用格局为：
addrepcluster $zk_cluster_follower $zk_root_path_follower $cluster_alias比方须要增加的从集群的 ZooKeeper 地址为 10.1.1.1:2181，OpenMLDB 在该 ZooKeeper 上的根门路为 10.1.1.2:2181 /openmldb_cluster，增加当前的从集群别名为 prod_dc01，则能够在主集群的 NS client 上执行如下命令进行从集群的增加：
addrepcluster 10.1.1.1:2181,10.1.1.2:2181 /openmldb_cluster prod_dc01移除从集群
能够执行命令 removerepcluster 来删除一个从集群，比方删除下面增加的从集群 prod_dc01：
removerepcluster prod_dc01切换集群角色
switchmode 命令能够批改集群的角色。参数能够为 leader 或者 normal。如果须要把从集群晋升成主集群，参数设置为 leader。如果要批改为一般的集群，参数设置为 normal。
switchmode leader查看从集群
showrepcluster 命令能够查问所有从集群，输入后果相似：
FAQ
Q1: 如何解决分布式的“脑裂”问题？
A1: 在分布式环境中，常常会遇到“脑裂”问题。所谓脑裂，简略来说就是在某些非正常状态下（比方因为网络阻塞），两个集群选举出了不同的 leader。Raft 之类的一致性协定能很好的解决相似问题，如要求 leader 必须获取半数以上的投票。
OpenMLDB 的选主和这些协定不太一样，OpenMLDB 是由 ZooKeeper 和 nameserver 来选主的。节点是否下线通过 ZooKeeper 中 ephemeral node 实现，nameserver 选主的时候从该集群的所有 follower 中抉择 offset 最大的一个作为新的 leader，所以实质上来说 OpenMLDB 的主从集群计划不会呈现脑裂的问题。
Q2: 如何判断主集群不可用，须要进行主从切换？
A2: 目前 OpenMLDB 在集群整体不可用的状态上并不会主动判断或主动切换，设计主从集群计划次要是为了应答如机房断电等重大事故。
因而目前须要人为主观去判断主集群是否处于不可用状态，从而须要进行主从切换。造成主集群不可用的常见起因如：整个集群的服务器不可抗拒起因无法访问、ZooKeeper 无奈复原、局部 tablet 下线导致无奈复原或者复原工夫过长等。
Q3: 是否可能在某些状况下会数据失落？
A3: 尽管主从集群计划减少了多一层的高可用机制，然而也不能保证数据齐全不失落，以下状况仍然会呈现数据失落，相干问题均会在后续版本进行修复或者优化：
- 主集群外部 tablets failover 后，新选出来的 leader 的 offset 比从集群中的 leader 的 offset 小，会造成两者 offset 差值之间的这部分数据失落
- 主从切换过程中，如果主集群有写流量，那么可能会造成局部未及时从原有主集群同步到从集群的数据失落
- 从集群表格拓扑发生变化，并且主集群尚未捕捉，此时如果执行主从切换，会造成从拓扑构造发生变化到切换胜利之间的数据失落
Q4: 是否能够反对多个从集群
A4: 一个主集群能够反对多个从集群，只有在主集群上执行增加从集群命令 addrepcluster 进行增加即可。
Q5: 和业界其余主从集群计划的比拟？
A5:
列举了两个业界罕用数据库作为比拟 —— TiDB 和 MySQL，OpenMLDB 的做法和这两个在架构上比拟类似。TiDB 将数据从 TiKV 传到 TiFlash 也是通过相似形式实现的，TiFlash 有一个 Learner 的概念相似于 OpenMLDB 从集群的 leader。TiKV 会把数据同步到 Learner 下面，而后再由 Learner 去做集群内的数据同步。MySQL 的主从复制，跟咱们做法也是相似的，它也是通过 binlog，将数据定期地同步到从集群下面，从集群再进行 binlog 的集群内读取和同步。
开发进度
目前主从集群计划在试验阶段，其外围性能都曾经开发结束，并且进行了充沛的测试。目前次要遗留问题为：
- SQL 命令目前只有创立表、删除表、以及数据插入操作能够主从集群主动同步，其余命令（比方 SQL 上线，批改 TTL 等）目前尚不反对主动同步，须要手动在主从集群上别离执行。
