MySQL数据库高可用与跨数据中心双活容灾

Percona的PXC，Galera以及MySQL 5.7之后的MGR等，其他的还有的MHA，

MySQL高可用复制管理工具：Orchestrator（orch）

数据库高可用HA（High Availability）是数据库的永恒话题，本文以MySQL为例，整理各种高可用方案，包括跨数据中心的容灾双活方案。

MySQL高可用方案

主从同步方式

高可用必然涉及集群、主从架构概念，都绕不开数据同步问题，即将一个节点的数据同步给另一个或多个节点。主从同步是一切高可用方案的基础。

数据复制原理

数据在MySQL节点间同步是通过自身的Bin-log日志来完成数据复制的，因为Bin-log日志中会记录所有对数据库产生变更的语句，包括DML数据变更和DDL结构变更语句。

MySQL同步实际采用的是“从节点拉取”方式，但与传统“从拉”方式需要从节点一直与主节点保持长连接，从节点定时或持续性的对主节点做轮询，查看主机的数据是否发生了变更的方式不同，主节点会有线程监听bin-log变化并通知丛节点拉取，减少资源消耗，具体过程如下：

1. 客户端将写入数据的需求交给主节点，主节点先向自身写入数据。
2. 数据写入完成后，紧接着会再去记录一份Bin-log二进制日志。
3. 配置主从架构后，主节点上会创建一条专门监听Bin-log日志的log dump线程。
4. 当log dump线程监听到日志发生变更时，会通知从节点来拉取数据。
5. 从节点会有专门的I/O线程用于等待主节点的通知，当收到通知时会去请求一定范围的数据。
6. 当从节点在主节点上请求到一定数据后，接着会将得到的数据写入到relay-log中继日志。
7. 从节点上也会有专门负责监听relay-log变更的SQL线程，当日志出现变更时会开始工作。
8. 中继日志出现变更后，接着会从中读取日志记录，然后解析日志并将数据写入到自身磁盘中。

同步复制

当主库执行完一个事务，然后所有的从都复制了该事务的 binlog 并写到 relay log，主库才返回成功信息给客户端。

同步复制方案能够确保数据100%不丢失和数据的强一致性，但同步复制的过程极其影响效率，因为需要等到所有从节点写完之后才返回数据，即保障CAP中的“CP”。

因为效率问题，同步复制一般不被使用，大部分对一致性要求高的数据库方案也只是使用半同步方式。

异步复制

异步复制是当主节点接收到一个客户端的写请求后，先会往自身写入数据，自身数据写入成功后，就会立马向客户端返回写入成功的信息，对于从节点的数据，会在其他的时间内再异步复制过去。

异步复制的优点是性能效率高，基本和MySQL单机版的写入效率差距不大；但异步复制的隐患是当主节点写入数据并返回成功后，还没有传到从节点之前就主节点崩溃，此时将从提升为主，会导致新主节点上的数据不完整。

异步复制是MySQL主从复制的默认方式。

半同步复制

半同步复制用于解决同步复制的写入效率问题和异步复制的数据丢失问题。

当客户端的数据到来时，会先写入到主节点中，接着主节点会向所有从节点发送一个写入数据的请求，但半同步模式中无需等待所有从节点全部写入完成后再返回，而是只要有一个从节点写入成功并返回了ACK，则会直接向客户端返回写入成功，这样既能够保证性能，又能够确保数据不丢失。

[!NOTE]

但实际上这种只要求一个节点返回ACK的半同步模式，依旧存在数据丢失风险，所以Zookeeper中，是要求收到一半从节点以上的ACK时，也就是一半从节点以上写入数据成功后，才会向客户端返回写入成功

半同步复制有两种模式：

1. AFTER_SYNC模式：master将新的事务写进binlog(buffer)，然后发送给slave，再sync到自己的binlog file(disk)。之后才允许接收slave的ack回复，接收到ack之后才会提交事务，并返回成功信息给客户端。（主先接收ack，再提交事务）
2. AFTER_COMMIT模式：master将新的事务写进binlog(buffer)，然后发送给slave，再sync到自己的binlog file(disk)，然后直接提交事务。之后才允许接收slave的ack回复，然后再返回成功信息给客户端。（主先提交事务，再接收ack）

AFTER_COMMIT模式存在主库提交事务后宕机风险，客户端未接收成功信息再次给新主库提交事务，可能导致事务重复提交（之前从库已接收事务）和原主库恢复为从库后是事务被重新提交。

因此，MySQL默认采用AFTER_SYNC模式，保证主从节点的数据强一致性，这种方式是后出的，因此称为增强半同步复制。

官方高可用方案

MySQL Replication

MySQL Replication 是官方提供的主从同步方案，用于实现数据从一个 MySQL 实例（称为源或主服务器，Master）自动复制到一个或多个其他 MySQL 实例（称为副本或从服务器，Slave），是目前应用最广的 MySQL 容灾方案。

MySQL Replication的原理即上一节中的主从同步方式，一般采用异步复制或半同步复制，因此说MySQL Replication也是一切高可用方案的基础。

MySQL Replication优点：

1、通过读写分离实现横向扩展的能力，写入和更新操作在源服务器上进行，从服务器中进行数据的读取操作，通过增大从服务器的个数，能够极大的增强数据库的读取能力；

2、数据安全，因为副本可以暂停复制过程，所以可以在副本上运行备份服务而不会破坏相应的源数据；

3、方便进行数据分析，可以在写库中创建实时数据，数据的分析操作在从库中进行，不会影响到源数据库的性能。

MySQL Replication的适用场景：

• 读密集型应用：在需要高读取性能的场景下，读写分离架构可以有效提升性能。
• 数据备份和容灾：用作数据实时备份和故障恢复的场景。
• 业务分布：适合对高可用要求不高的业务，允许丢数据及同步延迟。

MySQL Group Replication（MGR）

MySQL Group Replication 组复制，又称为 MGR。是 Oracle MySQL 于MySQL 5.7.17 推出的一个全新高可用和高扩展的解决方案，用于解决传统异步复制和半同步复制可能产生数据不一致的问题。

MGR 由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点 (N/2+1) 决议并通过，才能得以提交。

MySQL MGR 集群最少3个server节点共同组成的分布式集群，一种share-nothing复制方案，每个server节点都有完整的副本。

事务进入MGR层内部处理过程：应用发来的事务从MySQL Server经过MGR的APIs接口层分发到组件层，组件层去capture事务相关信息，然后经过复制协议层进行事务传输，最后经过GCS API+Paxos引擎层保证事务在各个节点数据最终一致性。

Paxos是一种经典的分布式一致性算法，类似于Raft协议，通过一系列的消息传递协议来确保数据一致性：

1. 提议者向接受者发送准备请求（Prepare）。准备请求包括一个提案编号（Proposal Number），它是一个唯一的、单调递增的编号，用于标识提议的版本号。接受者收到准备请求后，会检查提案编号是否比自己已经接受的提案编号更大，如果更大，那么接受者将自己已经接受的提案编号和对应的值（如果有的话）回复给提议者。否则，接受者忽略该请求。

2. 如果提议者收到了大多数接受者的回复，那么它就可以继续进行下一步操作。接着，提议者向接受者发送提交请求（Accept）。提交请求包括一个提案编号和一个值（Value）。如果接受者没有收到更高的提案，那么它会接受这个值，并将Accepted消息发送给提议者。

3. 如果提议者收到了大多数接受者的Accepted消息，那么它就可以将该提案决定为最终值（Decided），并将最终值发送给所有的学习者（Learner）。此时，所有的学习者都会接收到相同的最终值，并将其保存。

MGR支持单主模式和多主模式：

单主模式（Single Leader），集群中仅一个节点可写，其他节点只读。基于Paxos Single Leader实现，扩展读能力的同时保持高可用性。当主节点故障时，集群能够根据Paxos协议自主切换新主节点，保证数据强一致性。

多主模式（Multiple Leader），所有节点均可读写，主要用于扩展写能力。依赖Paxos协议的多点写入和行级别的冲突检测，保证数据顺序一致。

MGR优势：

1、避免脑裂：MGR 中不会出现脑裂的现象；

2、数据一致性保障：MGR 的冗余能力很好，能够保证 Binlog Event 至少被复制到超过一半的成员上，只要同时宕机的成员不超过半数便不会导致数据丢失。MGR还保证只要 Binlog Event 没有被传输到半数以上的成员，本地成员不会将事务的 Binlog Event 写入 Binlog 文件和提交事务，从而保证宕机的服务器上不会有组内在线成员上不存在的数据。因此，宕机的服务器重启后，不再需要特殊的处理就可以加入组；

3、多节点写入支持：多写模式下支持集群中的所有节点都可以写入。

MGR的适用场景：

1、弹性复制：需要非常灵活的复制基础设施的环境，其中MySQL Server的数量必须动态增加或减少，并且在增加或减少Server的过程中，对业务的副作用尽可能少。例如，云数据库服务；

2、高可用分片：分片是实现写扩展的一种流行方法。基于 组复制 实现的高可用分片，其中每个分片都会映射到一个复制组上（逻辑上需要一一对应，但在物理上，一个复制组可以承载多个分片）；

3、替代主从复制：在某些情况下，使用一个主库会造成单点争用。在某些情况下，向整个组内的多个成员同时写入数据，对应用来说可能伸缩性更强；

4、自治系统：可以利用组复制内置的自动故障转移、数据在不同组成员之间的原子广播和最终数据一致性的特性来实现一些运维自动化。

其他官方高可用方案

InnoDB Cluster

InnoDB Cluster 是官方提供的高可用方案,是 MySQL 的一种高可用性(HA)解决方案，它通过使用 MySQL Group Replication 来实现数据的自动复制和高可用性，InnoDB Cluster 通常包含下面三个关键组件：

1、MySQL Shell: 它是 MySQL 的高级管理客户端;

2、MySQL Server 和 MGR，使得一组 MySQL 实例能够提供高可用性，对于 MGR，Innodb Cluster 提供了一种更加易于编程的方式来处理 MGR;

3、MySQL Router，一种轻量级中间件，主要进行路由请求，将客户端发送过来的请求路由到不同的 MySQL 服务器节点。

MySQL Server 基于 MySQL Group Replication 构建，提供自动成员管理，容错，自动故障转移动能等。InnoDB Cluster 通常以单主模式运行，一个读写实例和多个只读实例。不过也可以选用多主模式。

优点：

1、高可用性：通过 MySQL Group Replication，InnoDB Cluster 能够实现数据在集群中的自动复制，从而保证数据的可用性；

2、简单易用：InnoDB Cluster 提供了一个简单易用的管理界面，使得管理员可以快速部署和管理集群；

3、全自动故障转移: InnoDB Cluster 能够自动检测和诊断故障，并进行必要的故障转移，使得数据可以继续可用。

InnoDB ClusterSet

MySQL InnoDB ClusterSet 通过将主 InnoDB Cluster 与其在备用位置（例如不同数据中心）的一个或多个副本链接起来，为 InnoDB Cluster 部署提供容灾能力。

InnoDB ClusterSet 使用专用的 ClusterSet 复制通道自动管理从主集群到副本集群的复制。如果主集群由于数据中心损坏或网络连接丢失而变得无法使用，用户可以激活副本集群以恢复服务的可用性。

InnoDB ClusterSet 的特点：

1、主集群和副本集群之间的紧急故障转移可以由管理员通过 MySQL Shell，使用 AdminAPI 进行操作；

2、InnoDB ClusterSet 部署中可以拥有的副本集群的数量没有定义的限制；

3、异步复制通道将事务从主集群复制到副本集群。clusterset_replication 在 InnoDB ClusterSet 创建过程中，在每个集群上都设置了名为 ClusterSet 的复制通道，当集群是副本时，它使用该通道从主集群复制事务。底层组复制技术管理通道并确保复制始终在主集群的主服务器（作为发送方）和副本集群的主服务器（作为接收方）之间进行；

4、每个 InnoDB ClusterSet 集群，只有主集群能够接收写请求，大多数的读请求流量也会被路由到主集群，不过也可以指定读请求到其他的集群；

中间件辅助高可用

除了MySQL官方的高可用方案，还有各种衍生的、利用各种插件中间件辅助实现的高可用方案。

Percona XtraDB Cluster（PXC）

PXC是由Percona开发，基于Galera协议的MySQL高可用方案，要求3节点起步防止脑裂。

Galera采用多主同步复制，确保数据一致性和高可用性，缺点是性能较弱，为此Galera采用组通信、事务重排序等方式提升性能。

对比项	Galera	MySQL Group Replication
组通信系统（Group Communication System）	专有组通信系统GComm，所有节点都必须有 ACK 消息	基于 Paxos，只要求大多数节点有 ACK 消息
二进制日志（Binlog）	不需要二进制日志，将二进制行事件写入Gcache	需要二进制日志
节点配置（Node Provisioning）	自动全量同步（State Snapshot Transfer，SST）与增量同步（Incremental State Transfer，IST）	没有自动全量同步，使用异步复制通道
全局事务ID（GTID）	使用状态UUID和递增序列号	依赖GTID，集群上的写操作产生GTID事件
分区控制（Partition Handling）	分区节点拒绝读写，自动恢复并重新加入集群	分区节点可读，接受写请求但将永久挂起，需要手工重新加入集群
流控（Flow Control）	当一个节点慢到一个限制值，阻止所有节点写	每个节点都有所有成员的统计信息，独立决定该节点写的阈值。如果有节点慢到阈值，其它节点放慢写速度。
DDL支持	总序隔离（Total Order Isolation，TOI），DDL执行期间，所有写入都将被阻止	DDL 并不会阻塞写，仅建议在单主模式下使用（因为 DDL 并没有冲突检测）

Galrea主要负责数据复制，原理如下：

当客户端发出commit命令时，在实际提交之前，对数据库所做的更改都将被收集到一个写集中，写集中包含事务信息和所更改行的主键。

然后，数据库将此写集发送到所有其它节点。节点用写集中的主键与当前节点中未完成事务的所有写集（不仅包括当前节点其它事务产生的写集，还包括其它节点传送过来的写集）的主键相比较，确定节点是否可以提交事务。同时满足以下三个条件则验证失败（存在冲突）：

• 两个事务来源于不同节点。
• 两个事务包含相同的主键。
• 老事务对新事务不可见，即老事务未提交完成。新老事务的划定依赖于全局事务总序，即GTID。

验证失败后，节点将删除写集，集群将回滚原始事务。对于所有的节点都是如此，每个节点单独进行验证。因为所有节点都以相同的顺序接收事务，它们对事务的结果都会做出相同的决定，要么全成功，要么都失败。成功后自然就提交了，所有的节点又会重新达到数据一致的状态。节点之间不交换“是否冲突”的信息，各个节点独立异步处理事务。由此可见，Galera本身的数据也不是严格同步的，很明显在每个节点上的验证是异步的，这也就是前面提到的“虚拟同步”。

最后，启动事务的节点可以通知客户端应用程序是否提交了事务。

PXC集群主要由两部分组成Percona Server with XtraDB和Write Set Replication patches（即基于Galera的用于事务型应用的同步、多主复制插件）。

client在执行insert del update 的时候，正常db1会返回执行的结果，如果不提交事务的话是不能持久化到数据库中的，想要真实的持久化就必须要提交事务。

首先在提交事务的时候,db1会把数据传递给pxc，pxc会复制当前节点的数据，然后分发给DB2和DB3，分发后要做的就是持久化这些数据。

事务的执行操作在pxc中会生产一个GTID编号，然后由db2 和db3去分别执行这个事务，每个db执行完成后会把结果返回给db1,然后db1收到其他db的执行结果后在本地也执行一下GTID的这个事务，db1执行完成后没问题的话最终会把执行的结果返回给客户端。

PXC优点：

• 同步复制，事务要么在所有节点提交或不提交。
• 多主复制，可以在任意节点进行写操作。 由于是多节点写入，所以DB故障切换很容易。完成了真正的多节点读写的集群方案；
• 在从服务器上并行应用事件，真正意义上的并行复制。 改善了主从复制延迟问题，基本上达到了实时同步；
• 节点自动配置，数据一致性，不再是异步复制。 新加入的节点可以自动部署，无需提交手动备份，维护方便；

PXC最大的优势：强一致性、实现了MySQL集群的高可用性和数据的强一致性；无同步延迟。

PXC缺点：加入新节点时开销大（XtraBackup等数据全量传输方式）；写扩大（所以节点上都会发生写操作，对于写负载过大的场景，不推荐使用PXC）；锁冲突（在多节点并发写入时，锁冲突问题比较严重）；脑裂（建议为基数，防止脑裂）等。

MMM

MMM（Master-Master replication manager for MySQL）是一套支持双主故障切换和双主日常管理的脚本程序，是很经典的高可用架构，但已停止维护。

MMM架构中，有一个专门的监控服务器安装mmm_monitor组件，配合安装在各个实例节点的mmm_agent组件，来监控各个实例的健康状况。

MMM架构中，有两个主，但只有一个主提供服务，它们之间互为主备，互相同步数据。

MMM架构中，对外提供的访问IP分为写VIP和读VIP。写服务访问写VIP，读服务访问读VIP中的一个。

当主挂掉之后，主和主备之间的同步也会中断，MMM工具会把原来挂在主服务器的多个salve迁移到主备上面，并且把写VIP也迁移到主备服务器上。

当某个从挂掉之后，比如从-1宕机，MMM管理工具会根据slave的负载情况，把原来绑定在从-1的读VIP-1迁移到其他的从服务器上，比如迁移到读VIp-3。这时，实际上，在从-3服务器上，就绑定了两个读VIP。

优点：

• 提供了读写VIP的配置，读写请求都可以达到高可用
• 工具包相对比较完善，不需要额外的开发脚本
• 完成故障转移之后可以对MySQL集群进行高可用监控

缺点：

• 故障简单粗暴，容易丢失事务，建议采用半同步复制方式，减少失败的概率
• 目前MMM社区已经缺少维护，不支持基于GTID的复制

MHA

Master High Availability Manager and Tools for MySQL，简称 MHA 。是一套主从架构的MySQL高可用方案。MHA支持主从切换，当发现 master 节点故障的时候，会自动提升其中拥有新数据的 slave 节点成为新的 master 节点，在此期间,MHA 会通过其他从节点获取额外的信息来避免数据一致性问题。MHA 还提供了 mater 节点的在线切换功能，即按需切换 master-slave 节点。MHA 能够在30秒内实现故障切换，并能在故障切换过程中，最大程度的保证数据一致性。

MHA 由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。

MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave节点上。MHA Node 运行在每台 MySQL 服务器上，MHA Manager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master。同时，将写VIP迁移到新的master，实现业务无感知。

MHA优势：

（1）支持基于GTID的复制和基于日志点的复制方式，相比于MMM架构工具只支持基于日志点的复制方式，MHA添加了对基于GTID的复制方式的支持

（2）可以从多个slave中选举最合适的新master

（3）会尝试从旧的master中尽可能多的保存未同步日志，可以保证在master宕机后，可以尽可能少的丢失事务。相比于MMM架构，MHA在这点上是MMM没有做到的。

	MMM	MHA	MGR	PXC
优点		成熟稳定、对MySQL侵入小、 宕机后保证数据一致	原生高可用、数据一致性保证、支持多主	类似MGR
缺点	太旧，2010年后停止维护；仅支持基于binlog的同步 不支持；MySQL5.6以后的提供的多线程同步技术 没有读负载的功能 主从切换时，容易造成数据丢失 ；MMM监控服务存在单点故障，避免的监控服务单点，需要自行实现	选主方式过时、需要配合第三方脚本进行自动切换；管理节点单点；MySQL异步复制中的数据丢失，不能保证数据强一致性	管理不方便（需配合mysql-shell）	性能损耗大（降低为1/3）、 大事务会卡住整个集群、需要用第三方发行版MySQL

Orchestrator

Orchestrator是go编写的MySQL高可用性和复制拓扑管理工具，支持复制拓扑结构的调整，自动故障转移和手动主从切换等。

Orchstrator提供Web界面展示MySQL复制的拓扑关系及状态，通过Web可更改MySQL实例的复制关系和部分配置信息，同时也提供命令行和api接口，方便运维管理。相对比MHA来看最重要的是解决了管理节点的单点问题，其通过raft协议保证本身的高可用。

Orchestrator主要特点：

① 自动发现MySQL的复制拓扑，并且在web上展示。

② 重构复制关系，可以在web进行拖图来进行复制关系变更。

③ 检测主异常，并可以自动或手动恢复，通过Hooks进行自定义脚本。

④ 支持命令行和web界面管理复制。

说明：

1、orchestrator组件很少，基本的就一个主程序文件，一个配置文件就够了。

2、orchestrator自己需要使用数据库存储元数据信息，因此需要为它专门建一个db，支持mysql和sqllite。

3、在mysql数据库服务器上，不需要做任何软件的安装，只需要新建一个用户给orchestrator使用即可，用户需要具备SUPER, PROCESS, REPLICATION SLAVE等权限。

相对比MHA的Manager的单点，Orchestrator通过Raft算法解决了本身的高可用性以及解决网络隔离问题，特别是跨数据中心网络异常。Raft通过共识算法：

Orchestrator节点能够选择具有仲裁的领导者（leader）。如有3个orch节点，其中一个可以成为leader（3节点仲裁大小为2，5节点仲裁大小为3）。只允许leader进行修改，每个MySQL拓扑服务器将由三个不同的orchestrator节点独立访问，在正常情况下，三个节点将看到或多或少相同的拓扑图，但他们每个都会独立分析写入其自己的专用后端数据库服务器：

① 所有更改都必须通过leader。

② 单个orchestrator节点的故障不会影响orchestrator的可用性。在3节点设置上，最多一个服务器可能会失败。在5节点设置上，2个节点可能会失败。

③Orchestrator节点异常关闭，然后再启动。它将重新加入Raft组，并接收遗漏的任何事件,只要有足够的Raft记录。

④ 要加入比日志保留允许的更长/更远的orchestrator节点或者数据库完全为空的节点，需要从另一个活动节点克隆后端DB。

在Raft模式下，三个Orchestrator节点各自挂载独立的数据库；除了Raft，还有一种方式是通过后端数据库同步保障Orchestrator高可用，原理是后端数据库基于Galera协议保障数据一致性和高可用。

Vitess

Vitess是一个用于部署、扩展和管理大型开源数据库实例集群的数据库解决方案，主要用于数据库分库分表、水平扩展，高可用依赖Orchestrator实现。

Topology(存储元数组)：元数据存储，用于存储 Vitess 集群的分片副本等配置信息，此外，在 master 选举，分布式锁中也会用到。对拓扑服务的要求是满足数据一致性的前提下尽量提高可用性。可选的拓扑服务器包括 etcd, ZooKeeper, consul.

VTTablet(代理MySQL实例)：VTTablet 是一个位于 MySQL 数据库前面的代理服务器。 Vitess 实现中每个 MySQL 实例前面都有一个 VTTablet 进程；VTTablet 是 Vitess 的最小工作单元，扮演一种 边车(sidecar) 进程的角色。MySQL 进程和 VTTablet 进程组合在一起叫做 Tablet，每一个分片都有一组tablet，一组Tablet里有master、replica和rdolny，基于Orchestrator实现高可用。

VTGate(入口网关/请求分发与合并)：VTGate 是一个轻型代理服务器，它接收客户端请求，将流量路由到正确的vttablet，并将合并的结果返回给客户端。应用程序向vtgate发起查询。客户端使用起来非常简单，它只需要能够找到vtgate实例就能使vitess。

MySQL双活容灾方案

MySQL高可用方案一般用于单个数据中心内多台数据库的服务器高可用与数据一致性保持（InnoDB ClusterSet和Vitess是支持跨数据中心的），为了防止单数据中心故障，需要跨数据中心AZ双活方案。

数据库主备节点分别部署在不同数据中心，利用第三个数据中心做仲裁区；数据层单写多读。

数据库高可用组件：实时检测主节点数据库状态，一旦故障，则走动将备节点提为主节点对外服务；三节点部署，在主备中心可以与数据库部署在同一节点，仲裁区独立部署，与主备中心网络可达。

一主一从模式，数据库节点分别部署到AZ1和AZ2中；引入仲裁区，和AZ1、AZ2一起部署高可用组件，组成三节点高可用；

• AZ1、AZ2任一个区故障，数据库整体服务不受影响。

一主两从模式（奇数），数据库一主一从节点部署在AZ1，数据库一从部署在AZ2；引入仲裁区，和AZ1、AZ2一起部署高可用组件，组成三节点高可用；（有一个备节点和主节点数据强一致，保证不丢数据,能达到RPO=0）

• 任一单节点数据库出现异常，数据库整体服务不受影响；
• 备可用区单节点故障，数据库整体服务不受影响；
• 主可用区两节点故障，需手工恢复数据库服务。