Mysql金融版成员管理

  简介

日前，华为云数据库推出MySQL金融版，基于Paxos协议，采用一主两备三节点架构，解决数据库分布式环境下数据一致性的问题，实现了自动脑裂保护机制，保证数据库高可用和高可靠，满足金融场景下的数据库高要求。

一主两备的三节点架构，是华为云MySQL金融版一大亮点。在该方案中，用户提交事务时，需要等待至少一个备库收到日志副本，才返回给用户事务成功结束的信号，且收到的确认事务会自动持久化到多数派主机中，确保数据库的可靠性。此外，在该架构下，无论任意一台服务器挂掉，也不影响业务可用性，因为已提交的数据至少有2份副本，挂掉一台，还有至少1台是包含了已提交事务的持久化内容。

Mysql金融版主要是通过Group Replication的开源插件来构建一主两备集群的，该插件由Mysql官方提供，其主要逻辑可以分为两部分：事务的处理逻辑和成员的管理逻辑；金融版的成员管理模块让Mysql具备了自动主从切换和故障恢复的能力，它能自动发现主节点crash，通过选主产生新的主节点对外提供服务。同时，旧的primary节点重启后，执行start group_replication即可将crash节点重新加入到Group中，在运维便利性和系统健壮性上有很大提升。本文主要分析Mysql金融版成员管理的主要逻辑。

基本原理

金融版的成员管理模块主要分为两大部分：成员状态管理，成员故障恢复；其中，成员状态管理通过对组视图的管理来实现，故障恢复是指成员加入组，完成视图切换后，将自己缺失的数据从其他成员上复制过来，从而达到金融版成员的一致性。

2.1 成员状态管理

2.1.1   组

Group Replication插件引入组（Group）的概念，上面提到的被Group Replication插件连接在一起的Mysql服务器为一个Group，Group内的成员分为主节点和备节点；Group的创建是在第一个成员启动的时候，组内各个Mysql节点均可以主动或被动的加入、离开Group，这就造成了Group成员状态的切换，Mysql成员管理即是在这种情况下起作用，保证金融版数据不丢失、高可靠。

2.1.2 组视图

组视图（View）是指Group在一段时间内的成员状态，如果在这段时间内没有成员变化，也就是说没有成员加入或退出，则这段连续的时间为一个视图，如果发生了成员加入或退出变化，则视图也就发生了变化，Mysql金融版使用视图ID（View ID）来跟踪视图的变化并区分视图的先后时间。

举例：

1. Group当前的视图ViewID为12345:2，该视图中包括2个成员，分别为DB1和DB2；

2. 一段时间后DB3节点请求加入Group，成功加入后视图切换为12345:3，包括3个成员，分别为DB1、DB2和DB3；

3. 之后DB2节点crash而退出了Group，视图切换为12345:4；

4. 之后DB4加入Group，视图切换为12345:5。

从上面的例子可以看出，viewID分为两部分：

• 前缀部分： Group初始化时产生，随机数，Group存活期间该值不会发生变化。所以，该字段可用于区分2个视图是否为同一个Group的不同时间点；

• 序号部分：Group初始化时，第一个视图的序号从1开始，其成员只有1个，为进行初始化的节点。以后Group出现任何成员的加入或退出序号都需要增1。

    在Group Replication插件启动后，也可以在performance_schema.replication_group_member_stats中查询到当前系统的ViewID。

2.1.3组视图切换

首先，以一个节点如何加入到Group为例：

1. 节点请求加入Group时，首先会根据配置的group_replication_group_seeds参数跟Group的种子成员建立TCP连接 （Gcs_xcom_control::do_join()）。该种子成员会根据自己的group_replication_ip_whitelist（ip白名单）检查是否允许新节点加入，金融版默认不限制新节点的ip。连接建立后，新节点发送请求申请加入组；

2. 收到请求后，leader广播视图变化的消息给Group中的所有节点，包括申请加入的节点；

3. 各个成员收到消息后开始做视图切换。首先，每个成员都会广播一个状态交换消息出去，每个状态交换消息包含了节点的当前状态和信息；

4. 发送了交换消息后，各个节点开始接收其他节点广播的消息，将其中的节点信息更新到本节点所维护的成员列表中；当收到所有成员中的最后一个状态交换消息时，通信模块将完整的新视图以视图数据包（View_change_log_event，包含冲突检测数据库）的形式返回给全局事务认证模块进行处理，视图切换至此结束；

这里，视图数据包会和事务数据一起走paxos协议，进入全局事务认证模块；事务认证模块会对每个事务数据包创建一个View_change_log_event（VCLE），写入Relay log，然后由group_replication_applier读取relay log中的VCLE，写入binlog；这样，VCLE将Binlog文件中的事务划分为多个区间，每个区间都代表一个视图内的事务；恢复阶段会用到VCLE。

  2.2 恢复

视图切换完成后，成员就正式加入到组内了，此时，它可以收到当前视图任何事务的数据包，但切换完成前是收不到的；因此，在成员加入组后，不能立即对外提供服务，需将自己缺失的数据从其他成员上复制过来，这就是恢复（Recovery）；在视图切换完成后，新成员会立即将自己的状态设置为recovering，表示正在恢复；

恢复过程分为三个阶段：本地恢复、全局恢复、缓存事务执行；

Mysql金融版所涉及的数据复制及其通道（channel）：

• group_replication_applier：金融版正常运行时，节点间通过Paxos协议传输事务数据，异地事务经过认证后写入relay log中，由该通道进行relaylog回放；

• group_replication_recovery：当有节点加入Group时，需要用到该通道，它是一个传统的Master-Slave异步复制通道。

  
  

  2.2.1本地恢复

   

  首先进行故障恢复初始化，包括故障恢复线程初始化，Group成员信息初始化等；

若待加入的成员是曾经加入过的节点，之前的Relay log可能还有一些未回放，需要先将这部分Relay log回放掉。

引入本地恢复的优点：提高恢复性能，无需在拉取这部分Binlog；提高恢复过程健壮性，减小所需Binlog被purge的风险。

本地恢复完成后，开始全局恢复。

2.2.2全局恢复

全局恢复是通过group_replication_recovery通道进行；金融版会随机选择一个online成员作为donor，然后进行复制通道配置，启动复制，复制时是基于GTID复制；

            恢复线程随机选择一个在线节点（donor），调用rpl_slave.cc中的request_dump函数建立与donor的复制关系，请求数据，该函数携带了恢复节点的gtid_executed信息。donor端会逆序遍历其Binlog文件，找到第一个不属于gtid_executed的事务，开始进行数据复制。

当碰到vcle的viewID等于当前viewID时，recovery通道会将vcle中携带的冲突检测数据库写入本节点，然后停止运行；

2.2.3 缓存事务执行

唤醒在被阻塞的认证队列处理线程，处理视图切换过程中缓存的事务，让本节点逐步跟上Group中的其他节点，进而将其设置为online。

这里，应该在什么时候允许节点online呢？金融版引入参数group_replication_recovery_complete_at进行控制，可选TRANSACTIONS_CERTIFIED或TRANSACTIONS_APPLIED（默认），分别表示认证队列为空或回放完所有已认证的事务时。在达到了group_replication_recovery_complete_at所确定的条件后，发送Recovery_message::RECOVERY_END_MESSAGE消息，通知Group中的各个节点，将该节点设置为在线状态。

2.2.4 手动恢复

需要手动恢复的场景：

• 待加入的节点加入时，滞后太久，其他节点的需要的binlog可能被purge了，这时，无法自动进行恢复；

• 当需要复制的binlog的非常多，使用异步复制效率低，需要花费很长时间；

手动恢复的方式：先利用备份数据，将待加入的节点恢复到一个比较近的时间节点，然后再加入Group；

  总结

本文主要介绍了，金融版的成员管理模块中的两大部分：成员状态管理，成员故障恢复；其中，成员状态管理介绍了组视图相关的概念及其实现，故障恢复介绍了成员加入组，完成视图切换后，恢复的几个主要阶段，包括本地恢复、全局恢复、缓存事务执行。正因为这样的机制，金融版具有高可用和高可靠的特点，且大大减少了传统主备架构下，主从切换的时间和成本。