MGR实现mysql高可用性
一。MGR和PXC的区别
1. PXC的消息广播机制是在节点间循环的，需要所有节点都确认消息，因此只要有一个节点故障，则会导致整个PXC都发生故障。而MGR则是多数派投票模式，个别少数派节点故障时，一般不影响整体的可用性。这也是PXC存在的最大问题。
2. PXC的节点间数据传输除了binlog，还有个gcache，这相当于是给MySQL又增加两个黑盒子。而MGR则都是基于原生binlog的，没有新增黑盒子，运行起来更可靠，需要排障时也更方便。
3. 发生网络分区时，整个PXC集群都不可用。而MGR则至少还能提供只读服务。
4. PXC的流控机制影响更大，一旦触发流控，所有节点都受到影响。而MGR触发流控后，只会影响本地节点，不影响远程节点。当然了，MySQL的流控做的也比较粗糙，在GreatSQL中进一步完善和优化。
5. 执行DDL期间，整个PXC集群都不可同时执行DML，也就是说不支持Online DDL。而MGR是支持的，这也是很大的优势。
相对于传统主从复制（Replication），我认为MGR的优势有以下几点：
1. 主从复制非常容易产生复制延迟，尤其是当表中没有显式主键时。而在MGR里，要求表一定要有主键（或是可用作聚集索引的非空唯一索引），避免了这个问题。
2. 半同步复制中，一旦slave因为锁或其他原因响应慢的话，也会导致master事务被阻塞。MGR是采用多数派确认机制，个别节点响应慢对Primary节点的影响没那么大（不要选用AFTER模式）。
3. 主从复制没有类似MGR那样提供事务数据的一致性保证。MGR自带了事务数据一致性保障机制。
二。部署MGR集群
1.配置host解析：
2.配置vi /etc/my.cnf.d/mysql-server.cnf
[mysqld]
#开启GTID,必须开启
gtid_mode = ON
#强制GTID的一致性
enforce_gtid_consistency = ON
#binlog格式,MGR要求必须是ROW,不过就算不是MGR,也最好用
binlog_format = row
#server-id必须是唯一的
server-id = 1
#MGR使用乐观锁,所以官网建议隔离级别是RC,减少锁粒度
transaction_isolation = READ-COMMITTED
#因为集群会在故障恢复时互相检查binlog的数据,
#所以需要记录下集群内其他服务器发过来已经执行过的binlog,按GTID来区分是否执行过.
log-slave-updates = 1
#binlog校验规则,5.6之后的高版本是CRC32,低版本都是NONE,但是MGR要求使用NONE
binlog_checksum = NONE
#基于安全的考虑,MGR集群要求复制模式要改成slave记录记录到表中,不然就报错
master_info_repository = TABLE
#同上配套
relay_log_info_repository = TABLE
#组复制设置#记录事务的算法,官网建议设置该参数使用 XXHASH64 算法
transaction_write_set_extraction = XXHASH64
#相当于此GROUP的名字,是UUID值,不能和集群内其他GTID值的UUID混用,可用uuidgen来生成一个新的,
#主要是用来区分整个内网里边的各个不同的GROUP,而且也是这个group内的GTID值的UUID
loose-group_replication_group_name = '5dbabbe6-8050-49a0-9131-1de449167446'
#IP地址白名单,默认只添加127.0.0.1,不会允许来自外部主机的连接,按需安全设置
loose-group_replication_ip_whitelist = '127.0.0.1/8,192.168.6.0/24'
#是否随服务器启动而自动启动组复制,不建议直接启动,怕故障恢复时有扰乱数据准确性的特殊情况
loose-group_replication_start_on_boot = OFF
#本地MGR的IP地址和端口，host:port,是MGR的端口,不是数据库的端口
loose-group_replication_local_address = '192.168.6.151:33081'
#需要接受本MGR实例控制的服务器IP地址和端口,是MGR的端口,不是数据库的端口
loose-group_replication_group_seeds = '192.168.6.151:33081,192.168.6.152:33081,192.168.6.153:33081'
#开启引导模式,添加组成员，用于第一次搭建MGR或重建MGR的时候使用,只需要在集群内的其中一台开启,
loose-group_replication_bootstrap_group = OFF
#是否启动单主模式，如果启动，则本实例是主库，提供读写，其他实例仅提供读,如果为off就是多主模式了
loose-group_replication_single_primary_mode = ON
#多主模式下,强制检查每一个实例是否允许该操作,如果不是多主,可以关闭
loose-group_replication_enforce_update_everywhere_checks = on
3.加载插件：
[root@mgr1 ~]# mysql -e "show plugins;" | grep "group_replication"
如果没正确加载，也可以登入MySQL Server自行手动加载这个plugin：
[root@mgr1 ~]# mysql -e "install plugin group_replication soname 'group_replication.so'"
[root@mgr1 ~]# mysql -e "show plugins;" | grep "group_replication"
4.配置账号：
mysql> set session sql_log_bin=0;
mysql> create user repl@'%' identified with mysql_native_password by 'repl';
mysql> GRANT BACKUP_ADMIN, REPLICATION SLAVE ON *.* TO `repl`@`%`;
mysql> set session sql_log_bin=1;
#通道名字 group_replication_recovery 是固定的，不能修改
mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';
5.主库操作：
SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;
SELECT * FROM performance_schema.replication_group_members;
6.从库操作：
START GROUP_REPLICATION;
SELECT * FROM performance_schema.replication_group_members;
三。MGR的维护：
在 **单主模式** 下，有且只有一个（Primary）节点可以写入数据，其余（Secondary）节点都只能读数据。而在 **多主模式** 下，可以在任意节点上同时读写数据。
1.切换主节点：
select group_replication_set_as_primary('52854f96-9314-11ee-8821-000c29ced34f');
注释：此id为想预定设置为primary的id
2.单主和多主模式间的切换：
切换多主(将所有主机变为primary)：select group_replication_switch_to_multi_primary_mode();
切换单主：select group_replication_switch_to_single_primary_mode('783eb73d-1a87-11f0-9ba9-000c2900b49e');使用某一个的id进行变为主，其他则变为从
3.添加新节点
首先，要先完成MySQL Server初始化，创建好MGR专用账户、设置好MGR服务通道等前置工作。接下来，直接执行命令 `start group_replication` 启动MGR服务即可，新增的节点会进入分布式恢复这个步骤，它会从已有节点中自动选择一个作为捐献者（donor），并自行决定是直接读取binlog进行恢复，还是利用Clone进行全量恢复。
如果是已经在线运行一段时间的MGR集群，有一定存量数据，这时候新节点加入可能会比较慢，建议手动利用Clone进行一次全量复制。还记得前面创建MGR专用账户时，给加上了 **BACKUP_ADMIN** 授权吗，这时候就排上用场了，Clone需要用到这个权限。
4.删除节点：
在命令行模式下，一个节点想退出MGR集群，直接执行 `stop group_replication` 即可，如果这个节点只是临时退出集群，后面还想加回集群，则执行 `start group_replication` 即可自动再加入。而如果是想彻底退出集群，则停止MGR服务后，执行 `reset master; reset slave all;` 重置所有复制（包含MGR）相关的信息就可以了。
5.重启集群：
正常情况下，MGR集群中的Primary节点退出时，剩下的节点会自动选出新的Primary节点。当最后一个节点也退出时，相当于整个MGR集群都关闭了。这时候任何一个节点启动MGR服务后，都不会自动成为Primary节点，需要在启动MGR服务前，先设置 `group_replication_bootstrap_group=ON`，使其成为引导节点，再启动MGR服务，它才会成为Primary节点，后续启动的其他节点也才能正常加入集群。
6.MGR事务监控：用于监控所有节点的信息
SELECT MEMBER_ID AS id, COUNT_TRANSACTIONS_IN_QUEUE AS trx_tobe_certified, COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE AS relaylog_tobe_applied, COUNT_TRANSACTIONS_CHECKED AS trx_chkd, COUNT_TRANSACTIONS_REMOTE_APPLIED AS trx_done, COUNT_TRANSACTIONS_LOCAL_PROPOSED AS proposed FROM performance_schema.replication_group_member_stats;