MySQL 8.x配置MGR高可用+ProxySQL读写分离（一）：MGR构建MySQL高可用

#作者：stackofumbrella

简介

MGR（MySQL Group Replication）是MySQL 5.7.17版本诞生的，是MySQL自带的一个插件，可以灵活部署。

保证数据一致性又可以自动切换，具备故障检测功能、支持多节点写入。
集群是多个MySQL Server节点共同组成的分布式集群，每个Server都有完整的副本，它是基于ROW格式的二进制日志文件和GTID特性。

MGR优点

强一致性：基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致的数据安全保证。

高容错性：只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制。

高扩展性：节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息。

灵活性：有单主模式和多主模式。单主模式下会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。优先使用单主模式。

MGR缺点

• 仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测。
  必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set；主从状态信息存于表中（-master-info-repository=TABLE 、-relay-log-inforepository=TABLE），-log-slave-updates打开。

• MGR不支持大事务，事务大小最好不超过143MB，当事务过大，无法在5秒的时间内通过网络在组成员之间复制消息，则可能会怀疑成员失败了，然后将其驱逐出局。
  目前一个MGR集群最多支持9个节点。

• 不支持外键于save point特性，无法做全局间的约束检测与部分事务回滚。
  二进制日志不支持Binlog Event Checksum。

MGR适用场景

• 金融交易、重要数据存储、对主从一致性要求高的场景。
• 核心数据总量未过亿。
• 读多写少，如：互联网电商。

单主模式和多主模式

组复制介绍

MGR对属于同一组中的服务器自动进行协调。对于要提交的事务，组成员必须就全局事务序列中给定事务的顺序达成一致，提交或回滚事务由每个服务器单独完成（即每台服务器都可以写数据或读数据），但所有服务器都必须做出相同的决定。如果存在网络分区，导致成员无法达成事先定义的分割策略，则在解决此问题之前系统不会继续进行，这是一种内置的自动裂脑保护机制。

MGR由组通信系统(Group Communication System ，GCS) 协议支持。该系统提供故障检测机制、组成员服务以及安全且有序的消息传递。

组复制插件架构图

MySQL组复制是一个MySQL插件，它基于常规的MySQL复制，利用了基于行格式的二进制日志和GTID等特性。下图是MySQL组复制的整体框架图。

1. 从上图的顶端开始，有一系列的API控制组复制插件如何和MySQL Server进行交互(图中灰色方框)。
2. 中间有一些接口可以使信息从MySQL Server流向组复制插件，反之亦然。这些接口将MySQL Server核心部分和插件隔离开来。在Server到插件的方向上，传递一些通知信息，例如server正在启动，server正在恢复，server已准备好接收连接，server将要提交事务等等。另一方向，即插件到server的方向上，插件会通知server对事务进行提交，终止正在进行的事务，将事务放进relay-log中排队等等。
3. 从API往下是一些响应组件，当通知信息路由到它们身上时就响应。capture组件负责跟踪正在执行的事务的上下文信息。applier组件负责在本节点上执行远程传输来的事务。recovery组件负责管理分布式恢复过程，还负责在节点加入组时选择donor，编排追赶过程以及对选择donor失败时的反应。
4. 继续向下，replication协议模块包含了特定的复制协议逻辑。它负责探测冲突，在组中接收和传播事务。
5. 后两层是组内通信系统(GCS)的API(第一个绿色方框)，以及一个基于Paxos组通信引擎的实现(implementation)(第二个绿色方框)。GCS API是组内通信API，它是一个上层API，它抽象了构建一个复制状态所需的属性，它从插件的更上层解耦了消息传递层。
6. 组通信引擎负责处理组内成员的通信。

单主模式

在单主模式下，组复制具有自动选主功能，group内只有一台节点可写可读，其他节点只可以读。对于group的部署，需要先跑起primary主节点，然后再开启其他节点，并把这些节点加进group。其他的节点就会自动同步primary节点上面的变化，然后设置为只读模式。

当primary主节点意外宕机或下线，在满足大多数节点存活的情况下，group内部发起选举，选出下一个可用的读节点提升为primary节点。

多主模式

在多主模式下，所有的MySQL节点都可以同时接受读写操作。group内的所有节点都是primary主节点，同时可以进行读写操作，并且数据是最终一致的。在多主模式下，不支持SERIALIZABLE事务隔离级别，且不能完全支持级联外键约束。

在mysql多主模式下，在组复制中通过Group Replication Protocol协议及Paxos协议，形成的整体高可用解决方案同时增加了certify的概念，负责检查事务是否允许提交，是否与其它事务存在冲突。Group Replication是由多个节点共同组成一个数据库集群，每个节点都可以单独执行事务，但是readwrite（rw）的操作只有在组内验证后才可以commit，Read-only (RO)事务是不需要验证可以立即执行，当一个事务在一个节点上提交之前，会在组内自动进行原子性的广播，告知其他节点变更了什么内容，执行了什么事务，然后为该事务建立一个全局的排序。最终这意味着所有的服务器都以相同的顺序接收相同的事务集。因此，所有服务器都按照相同的顺序应用相同的变更集，因此它们在组中保持一致。

配置主机名解析

$ sudo vim /etc/hosts
192.168.1.46 mysqlmaster
192.168.1.47 mysqlslave1
192.168.1.48 mysqlslave2
192.168.1.51 mysqlproxy

安装MGR插件

查找插件位置
$ sudo find / -name “group_replication.so”

主库配置
在主库原有配置上增加如下配置

# 设置MySQL插件目录：MGR基于插件，必须设置插件路径
plugin_dir=/usr/lib/mysql/plugin
# 开启binlog的GTID模式（MGR强制要求）
gtid_mode=ON
# 开启后MySQL只允许能够保障事务安全，并且能够被日志记录的SQL语句被执行
enforce_gtid_consistency=ON
# 关闭binlog校验（MGR强制要求）
binlog_checksum=NONE# 定义用于事务期间哈希写入提取的算法，组复制模式下必须设置为XXHASH64。
transaction_write_set_extraction=XXHASH64
# 服务器实例所在复制组名称，必须是有效的UUID，所有节点必须相同。
loose-group_replication_group_name="bbbbbbbb-bbbb-cccc-dddd-eeeeeeeeeeee"
# 确定服务器是否应该在服务器启动期间启动组复制。
loose-group_replication_start_on_boot=OFF# 为复制组中其他的成员提供的网络地址，指定为“主机:端口”的格式化字符串。
# 很多人想当然认为端口应该是3306，其实不然，MGR需要开启新端口24901同步交换
# 所以这里不要写错，可以配置主机名或IP地址
loose-group_replication_local_address="192.168.1.46:24901"# 用于建立新成员到组的连接组成员列表。
# 这个列表指定为由分隔号间隔的组成员网络地址列表，类似host1:port1、host2:port2的格式。
loose-group_replication_group_seeds="192.168.1.46:24901,192.168.1.47:24901,192.168.1.48:24901"# 配置此服务器为引导组，这个选项必须仅在一台服务器上设置，
# 并且仅当第一次启动组或重新启动整个组时。成功引导组启动后，将此选项设置为关闭。
loose-group_replication_bootstrap_group=OFF

slave1从库配置

plugin_dir=/usr/lib/mysql/plugingtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE# 这个参数决定primary节点到secondary节点的请求是否为基于RSA密钥对的密码交换所需的公钥
loose-group_replication_recovery_get_public_key=ON
loose-group_replication_recovery_use_ssl=ON
loose-group_replication_group_name="bbbbbbbb-bbbb-cccc-dddd-eeeeeeeeeeee"
loose-group_replication_start_on_boot=OFF# 设置slave1节点本机地址192.168.1.47:24901
loose-group_replication_local_address="192.168.1.47:24901"
loose-group_replication_group_seeds="192.168.1.46:24901,192.168.1.47:24901,192.168.1.48:24901"
loose-group_replication_bootstrap_group=OFF

slave2从库配置

plugin_dir=/usr/lib/mysql/plugingtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE# 这个参数决定primary节点到secondary节点的请求是否为基于RSA密钥对的密码交换所需的公钥
loose-group_replication_recovery_get_public_key=ON
loose-group_replication_recovery_use_ssl=ON
loose-group_replication_group_name="bbbbbbbb-bbbb-cccc-dddd-eeeeeeeeeeee"
loose-group_replication_start_on_boot=OFF# 设置slave2本机地址192.168.1.48:24901
loose-group_replication_local_address="192.168.1.48:24901"
loose-group_replication_group_seeds="192.168.1.46:24901,192.168.1.47:24901,192.168.1.48:24901"
loose-group_replication_bootstrap_group=OFF
重启各个节点
$ sudo systemctl restart mysql
导入插件，在每个节点都执行
INSTALL PLUGIN group_replication SONAME 'group_replication.so';

在主服务器的MySQL上执行下述命令

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

在两个从服务器上执行下述命令，执行之前应关闭MySQL主从复制线程

# 关闭复制线程
STOP SLAVE;# 指定主从账户与指定通信频道
CHANGE MASTER TO MASTER_USER="replica", MASTER_PASSWORD="123456" FOR CHANNEL 'group_replication_recovery';# 开启组网数据同步
START GROUP_REPLICATION;
查看成员状态信息
SELECT * FROM performance_schema.replication_group_members;

MGR故障转移

主节点下线重新选举
$ sudo systemctl stop mysql
在slave1节点查看集群状态
SELECT * FROM performance_schema.replication_group_members;

查看master的日志

查看slave1的日志

查看slave2的日志

可以看到slave1已经成为主库，由此可以说明MGR的选举策略为：

1. 优先低版本节点
2. 版本一样，优先权重大的节点
3. 版本与权重一样，按照server uuid的字母顺序选主

新主节点slave1下线，集群不可用
$ sudo systemctl stop mysql

SELECT * FROM performance_schema.replication_group_members;

在slave2上通过命令查看发现，slave1新主节点尽管已经下线，但slave2还在线，因为只有1个节点的情况下，少于n/2+1的规则，导致整体MGR集群失效，slave2节点无法产生选举

恢复MGR集群

只需要将三台服务器的MySQL分别重启，然后按照启动复制组的顺序执行命令即可恢复