本文介绍了Group Replication的两种工作模式的架构介绍。
并详细介绍了Single-Master Mode的部署过程，以及如何切换到Multi-Master Mode。
当然，文末给出了Group Replication的配置要求和一些限制。

〇 结构介绍

在2016年12月发布的5.7.17版本的MySQL，甲骨文宣布Group Replication已经GA。

Group Replication（下简称GR）有两个工作模式，分别为Single-Master Mode与Multi-Master Mode：


Single-Master Mode的failover图：

只有primary成员可读写，而其他的节点为只读，在primary成员发生故障时，将会有其他成员顶替成primary。


Multi-Master Mode的failover图：


所有的成员均可读可写。


关于脑裂问题，可发现MySQL Group Replication与MongoDB Relicate Set有相似之处：
和MongoDB的Relicate Set相近，其读写库类似于Primary，只读库类似于Secondary。

（下图来自MySQL官方）


（下图来自MongoDB 3.4 Manual）

〇 部署

测试实例数量：3台
版本：MySQL 5.7.17

安装（此处用的是二进制包安装）
mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz


创建数据目录及日志目录：

解压二进制包并将其设置为basedir：

〇 添加第一台实例：
添加3306实例的配置文件：

初始化3306实例datadir：

启动3306实例：

通过MySQL Client进入第一个实例（密码为空）

创建复制用户与授权，并让其作为group的第一个成员：

安装GR插件：

可以检查一下是否安装成功：

开启第一个组复制：

检查一下组复制成员，其中member_id就是@@server_uuid的值

添加测试数据：

〇 添加第二个实例（3307）
修改3307配置文件，将3306改成3307，并且将loose-group_replication_local_address的端口从24901改成24902：

初始化3307实例：

启动3307实例：

通过MySQL Client进入3307实例：

重复在3306实例的操作：

在3307实例上安装GR插件，开启组复制：

检查一下成员状态：

过了一阵子再检查，仍然是RECOVERING。


再过一阵子检查，发现member_state被置为ERROR：

此时检查3306实例的组复制情况，发现检查不到另一个实例的信息了：

开多一个终端，检查3307实例的error log发现：

应该是解析的问题，修改hosts文件，在末尾加上主机名：

重新操作3307实例：

检查组复制状态，发现两个实例的状态均为ONLINE了：

在3307上检查一下同步状态：

〇添加3308实例：
修改3308配置文件：

然后初始化并启动3308实例：

同样进入3308实例：

在3308实例上重复操作：

继续重复操作，安装GR插件并启动它：

最后再检查一下组复制成员的状态：

当然在3308实例上也已将3306的事务apply过来了：

root@localhost用户在上述操作中为空密码，可以给root@localhost加个密码……
因为三个实例都在一个GR组里，所以对3306实例操作就行了：

当然ALTER操作会被记录到3306的binlog里，并同步到3307和3308实例上。


可以查看一下三台实例的read_only和super-read-only值：

可以发现只有3306实例也就是第一个实例属于可写实例，而3307和3308均为read-only模式。
决定因素为第一个加入该GR组的成员，之后加入该GR组的均为ro，在该模式与MongoDB Replicate Set很相似。


当然如果要确定哪一个成员是primary，可以在三个成员中的任意一个执行：

至此，Group Replication默认的single-master mode已经搭建完毕。

〇 将Single-Master Mode修改为Multi-Master Mode

如果要将Single-Master Mode修改为Multi-Master Mode，也比较简单。
考虑到此时的Primary成员是3306，并且假定3306实例在对外提供写服务，我这边的操作如下：


首先停掉两个secondary的组复制，在3307和3308实例上操作：

再在3306实例上重复以上操作：

然后在3306上作为第一个成员启动组复制：

在停启组复制的过程中，3306实例仍对外提供服务，此处模拟修改：

再3307和3308两个实例上分别开启组复制：

并检查3307和3308是否将3306的事务应用过来：

当然可以看到，在3306上做的修改，在3307和3308开启组复制之后也已经同步过来了。


那么再检查一下3307和3308是否可写：

显然和Single-Master Mode不一样的是，除了3306实例，另外两个成员也就是3307和3308实例均为可写成员了。
也就是所谓的Multi-Master Mode。


当然可以测试一下：
在3307实例上做insert，在3308实例上update，最后在3306上查询：

至此，已经成功将Single-Master Mode修改为Multi-Master Mode。


P.S. 在多主模式中，已经不能通过下述SQL来查询primary member是哪一台实例了……虽然??明白为毛，可能在后续版本会改进？？？（猜测）
但总之在多主模式中，每一台status为online的成员都是primary。

总之……看起来很好用的样子。



从零开始搭建Multi-Master Mode的GR同样也很简单，可以参考：
 http://mysqlhighavailability.com/mysqlha/gr/doc/getting_started.html


两种工作模式在配置参数上的核心差别为：

〇 要求和限制

仅可用于InnoDB存储引擎（需要事务的支持和行级锁）
表必须有主键（创建无主键的表不会报错，但在插入数据的时候会抛出：ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.）
必须启用GTID
必须开启二进制日志，并且其格式必须为ROW（binlog_format=row）
冲突DDl、DML只能在同一成员上执行成功
在多主结构中，不完全支持外键（单主结构中是没有问题的）
不支持serializable的事务隔离级别
只支持IPv4，并且需要低延迟，高带宽的网络环境
GR最大支持9个成员
复制信息元数据必须存在系统表（master-info-repository=TABLE、relay-log-info-repository=TABLE）
二进制日志checksums必须关闭（binlog-checksum=NONE）
不支持savepoint的使用