MySql高可用集群之MGR（MySQL Group Replication）

一、MGR

---- MGR （MySQL Group Replication）是MySQL自带的一个插件，可以灵活部署。MySQL MGR集群是多个MySQL Server节点共同组成的分布式集群，每个Server都有完整的副本，它是基于ROW格式的二进制日志文件和GTID特性。架构主要是APIs层、组件层、复制协议模块层和GCS API+Paxos引擎层构成。
----应用发来的事务从MySQL Server经过MGR的APIs接口层分发到组件层，组件层去capture事务相关信息，然后经过复制协议层进行事务传输，最后经过GCS API+Paxos引擎层保证事务在各个节点数据最终一致性。这是事务进入MGR层内部处理过程。

三个组件

1. 支持 Group Replication 功能的 Mysql Server，主要功能在于实现了组内通信、故障转移和故障恢复；

2. Mysql-Shell：实现快速部署，主要提供了一套 AdminAPI，可以自动化配置 Group Replication。

3. Mysql-Router：内置读写分离，负载均衡。自动根据 Mysql InnoDB Cluster中的 metadata.

   MGR由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。由3个节点组成一个复制组，Consensus层为一致性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务才能够最终得以提交并响应。 引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案，给我们实现多活方案带来了希望。

二、MGR架构

MySQL MGR（MySQL Group Replication）是一个高可用性和容错性的解决方案，旨在提供数据冗余和故障转移。

1. 高一致性，基于原生复制及Paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；
2. 高容错性，只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；
3. 高扩展性，节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；
4. 高灵活性，有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。

2.1 故障检测
······组复制自带提供一种故障检测机制，这个机制能报告哪个组成员是无响应的，并且如何判断该成员是否排除集群组。在组复制中故障检测是一种分布式服务。假设服务器A在预定时间段内未收到来自服务器B的消息，如果组内其他成员也同样未收到来自服务器B的消息，那么确认判断B发生故障，这样由其他成员判定将失联组成员从集群中剔除。
······此时服务器B与其他服务节点都无法联系。由于无法达成最小仲裁成员数，处于独立状态，无法对外提供服务。

2.2容错
····MySQL组复制构建在Paxos分布式算法基础上实现的，以提供不同server之间的分布式协调。因此，它需要大多数server处于活动状态以达到仲裁成员数，从而做出决定。这对系统可以容忍的不影响其自身及其整体功能的故障数量有直接影响。容忍f个故障所需的server数量(n)n = 2 * f + 1。
····实践中，这意味着为了容忍一个故障，组必须有三个server。如果一个服务器故障， 仍然有两个服务器形成大多数(三分之二)来允许系统自动地继续运行。但是，如果第二个server意外地宕掉，则该组锁定(只有一个server)，因为没有达到多数可以达成选举(不能自己选举自己)。：

2.3举例
·····在MySQL MGR的三节点集群中，如果宕掉了两个节点，集群的行为将取决于节点的宕机方式。如果节点是正常关闭的，剩下的节点将继续运行并提供服务，但失去了冗余性。如果节点是异常宕机的，且超过半数的节点不可达，整个集群将变得不可用，直到剩余的节点被重启并重新加入集群。为了避免这种情况，建议在设计MGR集群时考虑使用更多的节点，以增加冗余性和容错能力。

正常关闭：（三节点停用俩节点）
······如果两个节点是正常关闭的（例如，通过执行STOP GROUP_REPLICATION命令），它们会向MGR集群发送退出信号。在这种情况下，这两个节点将被视为正常退出，而剩下的一个节点将被提升为Primary角色，并继续处理读写操作。此时，集群失去了冗余性，因为只有一个节点在运行。当其他节点再次启动并加入集群后，集群将恢复其完整性和高可用性。

异常宕机：（三节点停用俩节点）
······如果两个节点由于网络故障、mysqld进程崩溃或被误杀等原因异常宕机，这些节点将被标记为UNREACHABLE状态。在这种情况下，MGR会等待group_replication_member_expel_timeout时长（默认为10秒），之后这些节点将被正式从集群中剔除。如果此时超过半数的节点（在这个例子中是两个节点）处于UNREACHABLE状态，整个集群将被标记为不可用，无法提供读写服务。在这种情况下，需要重启剩余节点的MGR服务以恢复集群的正常运行。

三、ProxySQL

---- ProxySQL 是一款轻量级中间件，它支持 Query 路由，支持动态指定某个 SQL 进行缓存，并且可以动态加载配置（无需重启 ProxySQL 服务）、另外可 以配合 MGR 完成故障切换和读写分离。

-----ProxySQL工作原理：它通过 6032 端口代理 MySQL 服务，使用 mysql_users 配置数据 库用户，使用 mysql_group_replication_hostgroups 定义 mgr 集群的写组、备写组、 读组、离线组，使用 runtime_mysql_servers 定义数据源。服务启动后，代理服务 把 MGR 集群状态更新到 runtime 层。使用 mysql_query_rules 配置读写分离规则 （用户自定义）后，根据 server 表的数据库状态，分别把只读请求路由到读组的 集群节点（即 MGR secondary 节点），事务和写请求路由到写组的集群节点（即 MGR Primary 节点）。当 Primary 节点故障时，ProxySQL 会实时探测集群状态变化，把新 Primary 节点更新到写组，这样新的请求依然可以正确访问到写组的数 据库节点。如果 MGR 的 Secondary 节点故障，ProxySQL 会把该节点踢出只读组， 直到集群恢复后，它将自动更新到读组。

四、配置MGR

---- 4.1 安装数据库（略）
---- 4.2 各数据库配置文件

[mysqld]
bind-address=0.0.0.0
datadir=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64/data
basedir=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64
port=3306
socket=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64/data/mysqld.sock
user=mysql
# 每个节点要求不一样
server_id=${serverId}
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
innodb_buffer_pool_size=1g
# 8.0 默认值XXHASH64，针对写事务进行哈希处理
transaction_write_set_extraction=XXHASH64
# 启动加载组复制插件
plugin_load_add='group_replication.so'
# 集群唯一ID
group_replication_group_name="8d3cebd8-b132-11eb-8529-0242ac130003"
# 是否启动MySQL服务时启动组复制，建议值:off
group_replication_start_on_boot=off
# 本地IP后面端口33061可自定义，集群通信端口，建议统一端口
group_replication_local_address= "10.10.1.214:33061"
# 初始化集群成员列表，可动态修改
group_replication_group_seeds= "10.10.1.214:33061,10.10.1.217:33061,10.10.6.91:33061"
# 判断是否为引导组
group_replication_bootstrap_group=off
# 设置白名单，这里特别注意，如果是同网段可以不用设置，如果是不同网段则需要修改否则通信端口不可访问
loose-group_replication_ip_whitelist='10.10.1.214,10.10.1.217,10.10.6.91'

4.2.1 引导节点初始化（单主）
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
INSTALL PLUGIN group_replication SONAME 'group_replication.so';#安装对应插件
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
SELECT * FROM performance_schema.replication_group_members;

4.2.2 从节点
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
START GROUP_REPLICATION;
SELECT * FROM performance_schema.replication_group_members;


4.2.3 多主
各节点加入集群前需设置多一属性
set global group_replication_single_primary_mode=off;