在搭建MySQL复制的时候，你是否还在执行备份恢复，从库进行change master to的操作？如果是，那你可就真的落后了。
MySQL官方推荐的一款高可用集群方案MySQL Group Replication，简称：MGR(组复制)。它是官方推出的一种基于Paxos协议的状态机复制，彻底解决了基于传统的异步复制和半同步复制中数据一致性问题无法保证的情况，也让MySQL数据库涉及的领域更广，打开互联网金融行业的大门。
2016年12月 MySQL Group Replication推出了第一个GA版本发布在MySQL5.7.17中。如今，MySQL8.0版本即将与我们见面，再加上官方逐渐成熟的高可用集群 Group Replication方案，到时候谁还是我们MySQL的对手？全都不在了！MySQL数据库就是作者的信仰，爱你无怨无悔。
一、MGR组复制原理
首先我们来谈谈什么叫做组复制。
组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的Server集群。复制组由多个Server成员组成，如下图的Master1、Master2、Master3，所有成员独立完成各自的事务。
当客户端发起一个更新事务时，该事务先在本地执行，执行完成之后就要发起对事务的提交操作。在还没有真正提交之前，需要将产生的复制写集广播出去，复制到其它成员。如果冲突检测成功，组内决定该事务可以提交，其它成员可以应用，否则就回滚。
最终，所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改，保证组内数据强一致性。
二、MGR组复制模式
组复制可以在两种模式下运行：
-
单主模式下，组复制具有自动选主功能，每次只有一个 Server成员接受更新，其它成员只提供读服务。
-
多主模式下，所有的Server 成员都可以同时接受更新，没有主从之分，成员角色是完全对等的。
组复制默认情况下是单主模式，我们可以通过设置参数，让其变成多主模式。
group_replication_single_primary_mode=off
三、MGR特性介绍
MGR的特性在于：
-
完成了真正的多节点读写的集群方案；
-
基于原生复制及Paxos协议的组复制技术，并以插件的方式提供，实现了数据的强一致性；
-
由于是多节点读写，Failover切换变得更加简单；
-
增加删除节点，自动完成同步数据和更新组内信息的操作，扩展性增强。
虽然在MGR的多主模式下有不能支持串行隔离级别和不支持外键级联操作的限制条件，且目前MySQL版本中存在由于对DDL语句操作无法实现回滚，导致MGR无法对DDL语句做数据冲突检验，以致DDL语句在MGR中并发执行存在隐患的情况。但这些都不能阻挡MGR的发布所带来的开创新时代的意义。
四、MGR搭建实战演练
环境介绍：
这里我们准备三个节点，数据库版本使用MySQL5.7.17。
实战第1步：
在三个节点上执行安装MySQL5.7操作。（安装过程省略）
实战第2步：
在三个节点上分别设置hostname和IP地址的映射关系。
实战第3步：
在三个节点上分别创建复制账号，命令如下：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%' IDENTIFIED BY '!QAZ2wsx#EDC';
实战第4步：
安装GR插件之前需要配置my.cnf，然后重启MySQL，如下：
[mysqld] #skip-grant-tables # # Remove leading # and set to the amount of RAM for the most important data # cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%. # innodb_buffer_pool_size = 128M # # Remove leading # to turn on a very important data integrity option: logging # changes to the binary log between backups. # log_bin # # Remove leading # to set options mainly useful for reporting servers. # The server defaults are faster for transactions and fast SELECTs. # Adjust sizes as needed, experiment to find the optimal values. # join_buffer_size = 128M # sort_buffer_size = 2M # read_rnd_buffer_size = 2M datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid #Group Replication server_id = 1773306 #MGR一定要开启GTID功能gtid_mode = ON，enforce_gtid_consistency = ON gtid_mode = ON enforce_gtid_consistency = ON #MGR需要多源复制功能，所以需要将主从库之间的信息记录到表中。设置master_info_repository = TABLE和relay_log_info_repository = TABLE master_info_repository = TABLE relay_log_info_repository = TABLE #MGR在当前MySQL版本中，必须要设置binlog_checksum=none，并且binlog_format=row binlog_checksum = NONE log_slave_updates = ON log_bin = binlog binlog_format= ROW #MGR中开启主键信息采集功能：transaction_write_set_extraction= XXHASH64 transaction_write_set_extraction = XXHASH64 #MGR中需要设置组的名字，该group_replication_group_name是通过select uuid()或者$uuidgen来生成的。 loose-group_replication_group_name = '00393352-0f4e-4dc5-938d-148829aeaf24' loose-group_replication_start_on_boot = off #MGR中本地成员的地址由该参数group_replication_local_address决定，本例中当前节点是proxysql。 #后面的端口是每个节点都需要一个独立的TCP端口号，节点之间通过这个端口号进行通信。 loose-group_replication_local_address = 'proxysql:33061' #MGR中其他成员的地址由这个参数group_replication_group_seeds决定 loose-group_replication_group_seeds ='proxysql:33061,node2:33062,node3:33063' loose-group_replication_bootstrap_group = off #MGR采取多主模式时，需要关闭该参数：group_replication_single_primary_mode=off（默认是单主模式）。 loose-group_replication_single_primary_mode=off #于此同时，还需要将该参数：group_replication_enforce_update_everywhere_checks=true，目的则是为了做多主模式限制检测。 loose-group_replication_enforce_update_everywhere_checks=true #注：加载到参数文件里面，需要在每个参数的前面加loose。 #这里再强调一个参数：group_replication_auto_increment_increment #该参数代表自增属性，默认值为7。我们要保证每个成员的该值相同，并且建议该参数的设置尽量比组内成员的个数大一些，方便后期集群的扩展。
在三个节点上分别安装GR插件，命令如下：
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
组件安装完成之后，展示结果：
mysql> show plugins; +----------------------------+----------+--------------------+----------------------+---------+ | Name | Status | Type | Library | License | +----------------------------+----------+--------------------+----------------------+---------+ | binlog | ACTIVE | STORAGE ENGINE | NULL | GPL | | mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL | | sha256_password | ACTIVE | AUTHENTICATION | NULL | GPL | | CSV | ACTIVE | STORAGE ENGINE | NULL | GPL | | MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL | | InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL | | INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_LOCKS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_LOCK_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMPMEM | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMPMEM_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_PER_INDEX | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_PER_INDEX_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_PAGE | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_PAGE_LRU | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_POOL_STATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_TEMP_TABLE_INFO | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_METRICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_DEFAULT_STOPWORD | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_BEING_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_CONFIG | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_INDEX_CACHE | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_INDEX_TABLE | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLESTATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_INDEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_COLUMNS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_FIELDS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_FOREIGN | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_FOREIGN_COLS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLESPACES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_DATAFILES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_VIRTUAL | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL | | MRG_MYISAM | ACTIVE | STORAGE ENGINE | NULL | GPL | | PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | NULL | GPL | | ARCHIVE | ACTIVE | STORAGE ENGINE | NULL | GPL | | BLACKHOLE | ACTIVE | STORAGE ENGINE | NULL | GPL | | FEDERATED | DISABLED | STORAGE ENGINE | NULL | GPL | | partition | ACTIVE | STORAGE ENGINE | NULL | GPL | | ngram | ACTIVE | FTPARSER | NULL | GPL | | validate_password | ACTIVE | VALIDATE PASSWORD | validate_password.so | GPL | | group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL | +----------------------------+----------+--------------------+----------------------+---------+ 46 rows in set (0.00 sec)
实战第5步：
在192.168.1.177上启动首个节点的MGR集群服务。命令如下：
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='!QAZ2wsx#EDC' FOR CHANNEL 'group_replication_recovery';
注：MGR需要该异步复制通道，实现新节点加入集群自动从其他节点复制数据的目的，不需要手工指定从哪个节点复制，master_host和master_port信息都是自动完成。
注：执行初始化操作，只有首个节点需要这一步操作。(↓)
SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
启动成功之后，查看节点状态信息。命令如下：
SELECT * FROM performance_schema.replication_group_members;
关闭初始化操作命令如下：
SET GLOBAL group_replication_bootstrap_group = off;
注：replication_group_members表中MEMBER_STATE字段状态为ONLINE，再执行关闭初始化命令。
实战第6步：
在192.168.1.178上面启动第二个节点的MGR集群服务。命令如下：
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='!QAZ2wsx#EDC' FOR CHANNEL 'group_replication_recovery'; START GROUP_REPLICATION;
启动成功之后，查看节点状态信息。命令如下：
SELECT * FROM performance_schema.replication_group_members;
实战第7步：
在192.168.1.179上面启动第三个节点的MGR集群服务。命令如下：
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='!QAZ2wsx#EDC' FOR CHANNEL 'group_replication_recovery'; START GROUP_REPLICATION;
启动成功之后，查看节点状态信息。命令如下：
SELECT * FROM performance_schema.replication_group_members;
可见启动成功之后，三个成员的状态都是online，证明已经开始正常工作了。如此，就真正实现了多节点的读写操作。