MGR环境构建中需要考虑的细节（二）
MGR环境构建中需要考虑的细节（二）
这是学习笔记的第 1871篇文章
MGR配置中还是存在一些潜在的坑，还有一些相关的高可用实践，我们简单总结一下。
如果要完整的复现一下整个过程，除了参数部分，整个过程我整理出来了，供参考。
假设数据目录为 /data/mysql_4308
安装软件的目录为:/usr/local/mysql-5.7.25-linux-glibc2.12-x86_64
创建如下的目录结构
mkdir -p /data/mysql_4308/{data,log,innodblog,tmp}
sudo chown -R mysql.mysql /data/mysql_4308
修改参数my.cnf，把MGR相关的参数都屏蔽一下，安装后再开启
开始数据字典初始化，这个过程和之前最大的不同就是指定了文件的目录，比较奇怪的是，MySQL的这个安装有些太死板，有些参数顺序不一样都会出错。
/usr/local/mysql-5.7.25-linux-glibc2.12-x86_64/bin/mysqld --defaults-file=/data/mysql_4308/my.cnf --datadir=/data/mysql_4308/data --basedir=/usr/local/mysql-5.7.25-linux-glibc2.12-x86_64 --initialize-insecure
启动MySQL
/usr/local/mysql-5.7.25-linux-glibc2.12-x86_64/bin/mysqld_safe --defaults-file=/data/mysql_4308/my.cnf &
两个节点都做如下的配置：
创建复制账户
create user rpl_user@'%' identified by 'rpl_pass';
grant replication slave on *.* to rpl_user@'%' ;
安装插件
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
show plugins;
停止数据库
mysqladmin shutdown --socket=/data/mysql_4308/tmp/mysql.sock --port=4308
然后修改参数，开启group replication参数后重新启动
/usr/local/mysql-5.7.25-linux-glibc2.12-x86_64/bin/mysqld_safe --defaults-file=/data/mysql_4308/my.cnf &
开启一个通道：
change master to master_user='rpl_user',master_password='rpl_pass' for channel 'group_replication_recovery';
对于节点1来说，操作有些不同：
SET GLOBAL group_replication_bootstrap_group = ON;
set global slave_preserve_commit_order=on;
START GROUP_REPLICATION;
查看成员状态，这个时候MGR里面应该显示有一个online的成员。
SELECT * FROM performance_schema.replication_group_members;
对于节点2，可以参考如下的操作：
set global slave_preserve_commit_order=on;
START GROUP_REPLICATION;
SELECT * FROM performance_schema.replication_group_members;
对于MGR搭建来说，节点2的START GROUP_REPLICATION是关键，我搭建失败90%的问题都卡在了这里。
平均下来，我做的配置节点2生效大概是6秒左右，不会太长，如果几十秒基本就说明有问题了。
>>START GROUP_REPLICATION;
Query OK, 0 rows affected (5.79 sec)
如果节点1出现了宕机操作或者服务不可用，节点2会自动接管吗，答案是显然的。当然这也牵扯出一个问题，对于主库的重启还是要谨慎。
Primary: shutdown
Secondary只能看到一个online的节点，已有的Primary接单会退出，节点2会切换为主节点：
2019-01-26T06:01:13.675603Z 0 [Warning] Plugin group_replication reported: 'Members removed from the group: mysqlt-9-208:4308'
2019-01-26T06:01:13.675670Z 0 [Note] Plugin group_replication reported: 'Primary server with address mysqlt-9-208:4308 left the group. Electing new Primary.'
2019-01-26T06:01:13.675811Z 0 [Note] Plugin group_replication reported: 'A new primary with address mysqlt-119-221:4308 was elected, enabling conflict detection until the new primary applies all relay logs.'
2019-01-26T06:01:13.675910Z 35 [Note] Plugin group_replication reported: 'This server is working as primary member.'
2019-01-26T06:01:13.675968Z 0 [Note] Plugin group_replication reported: 'Group membership changed to mysqlt-119-221:4308 on view 15484796752622311:3.'
如果稍后把节点1启动，可以做一个类似Failback的操作，这点就充分显示出GTID模式下的好处了。
Failback:
Old Primary通过如下的方式启动：
>>set global slave_preserve_commit_order=on;
Query OK, 0 rows affected (0.00 sec)
>>START GROUP_REPLICATION;
Query OK, 0 rows affected (4.48 sec)
Old Secondary(new Primary)可以看到日志的细节：
2019-01-26T06:03:56.567538Z 38 [Note] Start binlog_dump to master_thread_id(38) slave_server(7238), pos(, 4)
2019-01-26T06:03:56.861092Z 0 [Note] Plugin group_replication reported: 'The member with address mysqlt-9-208 was declared online within the replication group'
如果要把集群主节点的关系恢复回来，可以把节点2停掉，让关系能够轮询过来。至少目前来看MGR的节点选择是自动的过程，还没有一个类似优先级的方式。
可以模拟一个Swithover的场景，即把节点2停掉。
Old Secondary(new Primary): shutdown
大概有1-2秒的时间差，主库的数据写入就能够重新感知到。
Primary:
>>create database test;
ERROR 1007 (HY000): Can't create database 'test'; database exists
此外还有一些经验，如果我们使用mysqldump导出一个文件，在导出的文件中默认会有GTID的设置，这个可以作为我们搭建从库的时候所用：
SET @@SESSION.GTID_NEXT= '1bb1b861-f776-11e6-be42-782bcb377193:3084'
但是在MGR里面是不可行的，因为reset master操作是不允许的，在已有数据的场景下我们要搭建级联环境是不可行的。
>>reset master;
ERROR 3190 (HY000): RESET MASTER is not allowed because Group Replication is running.
在环境部署后，我们可以通过业务对接的方式试运行一下，看看还有哪些潜在的问题。