最近绝地求生这个游戏太火了，当我问我的朋友们你们闲时在干嘛，基本上告诉我的答案都是在"吃鸡"啊！想必很多老铁们也玩，那一定应该知道绝地求生中有把枪叫AWM。此枪伤害裸132点，爆头330，即使三级头爆头必死，无防弹衣或者防弹衣有破损，一枪死。是这个游戏中威力最大的狙击×××，足足是98K的两倍。
那么在MySQL领域有没有这么一把威力超大的“枪”呢~答案是必须有啊！但老张先问你们一个问题。
请问你搭建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的发布所带来的开创新时代的意义。让我们一起期待这个追求极致完美的MySQL数据库，未来更加璀璨夺目。
MGR搭建实战演练
环境介绍：这里我们准备三个节点，数据库版本使用MySQL5.7.17
数据库IP地址 数据库版本信息 主机名 Server-id
192.168.56.101MySQL-5.7.17node21013306192.168.56.102MySQL-5.7.17node31023306192.168.56.103MySQL-5.7.17proxysql1033306
实战第1步：
在三个节点上执行安装MySQL5.7操作。（此步省略，详情请见书中第一部分第二章）
实战第2步：
在三个节点上分别设置hostname和ip地址的映射关系
实战第3步：
在三个节点上分别创建复制账号，命令如下
GRANTREPLICATIONSLAVEON*.*TO'repl'@'192.168.56.%'IDENTIFIEDBY'123456';
实战第4步：
在三个节点上分别安装GR插件，命令如下
INSTALLPLUGINgroup_replicationSONAME'group_replication.so';
组件安装完成之后，展示结果：
root@db13:23: [(none)]> show plugins;
实战第5步：
在三个节点分别配置各自的集群参数文件，配置完成之后重启数据库
192.168.56.101参数文件配置展示：（剩下两个节点同理）
Group Replication
server_id=1013306gtid_mode=ONenforce_gtid_consistency=ONmaster_info_repository= TABLErelay_log_info_repository= TABLEbinlog_checksum= NONElog_slave_updates=ONlog_bin= binlogbinlog_format= ROWtransaction_write_set_extraction= XXHASH64loose-group_replication_group_name='1f2cee29-f9a2-11e7-8cbb-08002783b39d'loose-group_replication_start_on_boot=offloose-group_replication_local_address='node2:33061'loose-group_replication_group_seeds='node2:33061,node3:33062,proxysql:33063'loose-group_replication_bootstrap_group=offloose-group_replication_single_primary_mode=offloose-group_replication_enforce_update_everywhere_checks=true
重点参数详解：（一定要记住这些）
MGR一定要开启GTID功能gtid_mode = ON，enforce_gtid_consistency = ON
MGR在当前MySQL版本中，必须要设置binlog_checksum=none，并且binlog_format=row
MGR需要多源复制功能，所以需要将主从库之间的信息记录到表中。设置master_info_repository = TABLE和relay_log_info_repository = TABLE
MGR中开启主键信息采集功能：transaction_write_set_extraction= XXHASH64
MGR中把该参数group_replication_single_primary_mode关闭目的是搭建多主模式。如果搭建单主模型，保持默认参数即可。
MGR中需要设置组的名字，该group_replication_group_name是通过select uuid()来生成的。
MGR中本地成员的地址由该参数group_replication_local_address决定，本例中当前节点是node2。后面的端口是每个节点都需要一个独立的tcp端口号，节点之间通过这个端口号进行通信。
MGR中其他成员的地址由这个参数group_replication_group_seeds决定
MGR采取多主模式时，需要让该参数group_replication_single_primary_mode=off（默认是单主模式）。
于此同时需要将该参数group_replication_enforce_update_everywhere_checks=true。目的是为了做多主模式限制检测。
注：加载到参数文件里面，需要在每个参数的前面加loose。
这里再强调一个参数group_replication_auto_increment_increment。该参数代表自增属性，默认值为7。我们要保证每个成员的该值相同，并且建议该参数的设置尽量比组内成员的个数大一些，方便后期集群的扩展。
实战第6步：
在192.168.56.101上启动首个节点的MGR集群服务。命令如下：
CHANGEMASTERTOMASTER_USER='repl', MASTER_PASSWORD='123456'FORCHANNEL'group_replication_recovery'
（MGR需要该异步复制通道，实现新节点加入集群自动从其他节点复制数据的目的，不需要手工指定从哪个节点复制，master_host和master_port信息。都是自动完成）
SET GLOBAL group_replication_bootstrap_group = ON;
（执行初始化操作，只有首个节点需要这一步操作）
START GROUP_REPLICATION;
启动成功之后，查看节点状态信息。命令如下
SELECT*FROMperformance_schema.replication_group_members;
