组复制有两种模式
单主模式(single-primary/single-master)下自动选举出一个主节点，从而只允许在同一时刻只有该主节点可以更新数据。
对于MySQL的高级使用人员，可以通过复制组实现多主模型(multi-primary)，这种模型下，所有的主节点都可以在同一时刻接受更新操作，即并发写。
MySQL组复制有一个内置的组成员服务(group membership service)，该服务动态维护组中成员以及可用成员的信息视图。每当有成员离开，加入的时候这个视图都会随之更新。
如果某MySQL实例在非预期的情况下离开了组，失败探测机制可以探测出这种情况并通知组，告知视图已经更改，这是自动完成的。
什么是MGR
MGR(MySQL Group Replication)是MySQL官方在MySQL 5.7.17版本中以插件形式推出的主从复制高可用技术，它基于原生的主从复制，将各节点归入到一个组中，通过组内节点的通信协商(组通信协议基于Paxos算法)，实现数据的强一致性、故障探测、冲突检测、节点加组、节点离组等等功能 。
这3个节点互相通信，每当有事件发生，都会向其他节点传播该事件，然后协商，如果大多数节点都同意这次的事件，那么该事件将通过，否则该事件将失败或回滚。
这些节点可以是单主模型的(single-primary)，也可以是多主模型的(multi-primary)。单主模型只有一个主节点可以接受写操作，主节点故障时可以自动选举主节点。多主模型下，所有节点都可以接受写操作，所以没有master-slave的概念。
MGR配置
1.配置环境
S1:10.16.208.5:6005
S2:10.16.208:4:6005
S3:10.16.18.3:6005
S1《--》S2《--》S3
配置时确保3哥节点的主机名不一样
配置组内第一个节点S1
1.修改配置文件
[mysqld] datadir=/data socket=/data/mysql.sock server-id=11701 # 必须 gtid_mode=on # 必须 enforce_gtid_consistency=on # 必须 log-bin=/data/master-bin # 必须 binlog_format=row # 必须 binlog_checksum=none # 必须 master_info_repository=TABLE # 必须 relay_log_info_repository=TABLE # 必须 relay_log=/data/relay-log # 必须，如果不给，将采用默认值 log_slave_updates=ON # 必须 sync-binlog=1 # 建议 log-error=/data/error.log pid-file=/data/mysqld.pid transaction_write_set_extraction=XXHASH64 #必须 loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" #必须 loose-group_replication_start_on_boot=off #建议设置OFF loose-group_replication_member_weigth = 40 #非必须,5.7.20开始支持 loose-group_replication_local_address="10.16.208.5:26005" #必须 loose-group_replication_group_seeds="10.16.208.5:26005,10.16.208.4:26005" #必须
- (1).因为组复制基于GTID，所以必须开启gtid_mode和enforce_gtid_consistency。
- (2).组复制必须开启二进制日志，且必须设置为行格式的二进制日志，这样才能从日志记录中收集信息且保证数据一致性。所以设置log_bin和binlog_format。
- (3).由于MySQL对复制事件校验的设计缺陷，组复制不能对他们校验，所以设置binlog_checksum=none。
- (4).组复制要将master和relay log的元数据写入到mysql.slave_master_info和mysql.slave_relay_log_info中。
- (5).组中的每个节点都保留了完整的数据副本，它是share-nothing的模式。所以所有节点上都必须开启log_slave_updates，这样新节点随便选哪个作为donor都可以进行异步复制。
- (6).sync_binlog是为了保证每次事务提交都立刻将binlog刷盘，保证出现故障也不丢失日志。
- (7).最后的6行是组复制插件的配置。以
loose_开头表示即使启动组复制插件，MySQL也继续正常允许下去。这个前缀是可选的。 - (8).倒数第6行表示写集合以
XXHASH64的算法进行hash。所谓写集，是对事务中所修改的行进行的唯一标识，在后续检测并发事务之间是否修改同一行冲突时使用。它基于主键生成，所以使用组复制，表中必须要有主键。 - (9).倒数第5行表示这个复制组的名称。它必须是一个有效的UUID值。嫌可以直接和上面一样全写字母a。在Linux下，可以使用
uuidgen工具来生成UUID值。
[root@xuexi ~]# uuidgen
09c38ef2-7d81-463e-bdb4-9459b2c0e49b
- (10).倒数第4行表示组复制功能不随MySQL实例启动而启动。虽然，可以将组复制插件和启动组复制功能的选项写在配置文件里，但强烈建议不要如此，而是每次手动去配置。
- (11).倒数第3行表示该节点在组中的权重为40。权重越高，自动选举为primary节点的优先级就越高。
- (12).倒数第2行表示本机上用于组内各节点之间通信的地址和端口。
- (13).最后一行，设置本组的种子节点。种子节点的意义在前文已经解释过了。
现在配置文件已经提供。可以启动mysql实例了。
[root@xuexi ~]# systemctl start mysqld
./mysql.server restart
2.创建复制用户
GRANT REPLICATION SLAVE ON *.* TO 'dmrepl'@'10.%.%.%'
3.配置节点加组时的通道,(关键)
在新节点加入组时，首先要选择donor。新节点和donor之间的异步复制就是通过一个名为group_replication_recovery的通道(通道名固定，不可使用自定义通道)进行数据恢复的，经过数据恢复后，新节点填充了它缺失的那部分数据，这样就和组内其他节点的数据保持了同步。
这个恢复过程比较复杂，它是一种分布式恢复。
change master to
master_user='repl',
master_password='P@ssword1!'
for channel 'group_replication_recovery';
这里的用户名、密码和通道在组复制中有一个专门的术语：通道凭据(channel credentials)。通道凭据是连接donor的关键。
当执行完上面的语句后，就生成了一个该通道的relay log文件(注意称呼：该通道的relay log，后面还有另一个通道的relay log)。如下，其中前缀"relay-log"是配置文件中"relay_log"选项配置的值。
-rw-r----- 1 mysql mysql 150 Feb 25 15:22 relay-log-group_replication_recovery.000001 -rw-r----- 1 mysql mysql 83 Feb 25 15:22 relay-log-group_replication_recovery.index
group_replication_recovery通道的relay log用于新节点加入组时，当新节点联系上donor后，会从donor处以异步复制的方式将其binlog复制到这个通道的relay log中，新节点将从这个recovery通道的relay log中恢复数据。
4.安装组复制插件启动组复制功能
install plugin group_replication soname 'group_replication.so';
启动组复制
(admin@g1-db-test-v07:6005)[(none)]>set global group_replication_bootstrap_group=ON; Query OK, 0 rows affected (0.00 sec) (admin@g1-db-test-v07:6005)[(none)]>start group_replication; Query OK, 0 rows affected (2.13 sec) (admin@g1-db-test-v07:6005)[(none)]>set group_replication_bootstrap_group=OFF;
这里的过程很重要，需要引起注意。在开启组复制之前，设置全局变量group_replication_bootstrap_group为on，这表示稍后启动的组复制功能将引导组，也就是创建组并配置组，这些都是自动的。配置引导变量为ON后，再开启组复制插件功能，也就是启动组复制。最后将引导变量设回OFF，之所以要设置回OFF，是为了避免下次重启组复制插件功能时再次引导创建一个组，这样会存在两个名称相同实际却不相同的组。
这几个过程不适合放进配置文件中，强烈建议手动执行它们的。否则下次重启mysql实例时，会自动重新引导创建一个组。同理，除了第一个节点，其他节点启动组复制功能时，不应该引导组，所以只需执行其中的start语句，千万不能开启group_replication_bootstrap_group变量引导组。
这里的几个过程，应该形成一个习惯，在启动第一个节点时，这3条语句同时执行，在启动其他节点时，只执行start语句。
-rw-r----- 1 mysql mysql 219 Feb 25 15:33 relay-log-group_replication_applier.000001 -rw-r----- 1 mysql mysql 638 Feb 25 15:33 relay-log-group_replication_applier.000002 -rw-r----- 1 mysql mysql 164 Feb 25 15:33 relay-log-group_replication_applier.index -rw-r----- 1 mysql mysql 150 Feb 25 15:22 relay-log-group_replication_recovery.000001 -rw-r----- 1 mysql mysql 83 Feb 25 15:22 relay-log-group_replication_recovery.index
是否还记得刚才用于恢复的通道group_replication_recovery？这个applier通道是干什么的？常规复制有两个复制线程：io线程和sql线程，在组复制中，不再称之为io_thread和sql_thread，取而代之的是receiver、certifier和applier。这里简单介绍一下它们的作用：
- receiver的作用类似于io线程，用于接收组内个节点之间传播的消息和事务。也用于接收外界新发起的事务。
- applier的作用类似于sql线程，用于应用relay log中的记录。不过，组复制的relay log不再是relay log，而是这里的组复制relay log：
relay-log-group_replication_applier.00000N。 - certifier的作用在receiver接收到消息后，验证是否有并发事务存在冲突问题。冲突检测通过后，这条消息就会写入到组复制的relay log中，等待applier去应用。
并不是说组复制中没有io线程和sql线程，而是称呼改变了，receiver和applier实际上就是io_therad和sql_thread。
5.验证组中节点并测试插入不满足组复制要求的数据
(admin@g1-db-test-v07:6005)[(none)]>select * from performance_schema.replication_group_members; +---------------------------+--------------------------------------+----------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+----------------+-------------+--------------+ | group_replication_applier | b3f6377f-52c5-11ea-92c4-be6f2b61965c | g1-db-test-v07 | 6005 | ONLINE | +---------------------------+--------------------------------------+----------------+-------------+--------------+
请注意这里的每一行，包括member_host，它是对外连接的地址，所以应该设置它的DNS解析为提供MySQL数据库服务的接口地址。这很重要，如果你不想去修改DNS解析，可以在启动组复制之前，设置report_host变量为对外的IP地址，或者将其写入到配置文件中。
现在，组中的这个节点已经是ONLINE了，表示可以对外提供组复制服务了。
下面创建4个表：t1和t4是InnoDB表，t3和t4具有主键。
(root@g1-db-test-v07:6005)[jhl]>create table t1(id int); Query OK, 0 rows affected (0.00 sec) (root@g1-db-test-v07:6005)[jhl]>create table t2(id int)engine=myisam; Query OK, 0 rows affected (0.04 sec) (root@g1-db-test-v07:6005)[jhl]>create table t3(id int primary key)engine=myisam; Query OK, 0 rows affected (0.00 sec) (root@g1-db-test-v07:6005)[jhl]>create table t4(id int primary key); Query OK, 0 rows affected (0.01 sec)
虽说组复制对这些有限制，但是创建时是不会报错的。
向这4张表中插入数据：
(root@g1-db-test-v07:6005)[jhl]>insert into t1 values(1); ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin. (root@g1-db-test-v07:6005)[jhl]>insert into t2 values(1); ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin. (root@g1-db-test-v07:6005)[jhl]>insert into t3 values(1); ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin. (root@g1-db-test-v07:6005)[jhl]>insert into t4 values(1); Query OK, 1 row affected (0.01 sec)
意思是该表不遵从外部插件(即组复制插件)的要求。
最后，查看下二进制日志中的事件
(root@g1-db-test-v07:6005)[jhl]>show binlog events in 'jhl_master-mysql-bin.000011'; +-----------------------------+------+----------------+-----------+-------------+-------------------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +-----------------------------+------+----------------+-----------+-------------+-------------------------------------------------------------------+ | jhl_master-mysql-bin.000011 | 4 | Format_desc | 11701 | 123 | Server ver: 5.7.24-log, Binlog ver: 4 | | jhl_master-mysql-bin.000011 | 123 | Previous_gtids | 11701 | 190 | b3f6377f-52c5-11ea-92c4-be6f2b61965c:1-6 | | jhl_master-mysql-bin.000011 | 190 | Gtid | 11701 | 251 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' | | jhl_master-mysql-bin.000011 | 251 | Query | 11701 | 310 | BEGIN | | jhl_master-mysql-bin.000011 | 310 | View_change | 11701 | 489 | view_id=15826159969082953:1 | | jhl_master-mysql-bin.000011 | 489 | Query | 11701 | 554 | COMMIT | | jhl_master-mysql-bin.000011 | 554 | Gtid | 11701 | 615 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' | | jhl_master-mysql-bin.000011 | 615 | Query | 11701 | 711 | use `jhl`; create table t1(id int) | | jhl_master-mysql-bin.000011 | 711 | Gtid | 11701 | 772 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' | | jhl_master-mysql-bin.000011 | 772 | Query | 11701 | 881 | use `jhl`; create table t2(id int)engine=myisam | | jhl_master-mysql-bin.000011 | 881 | Gtid | 11701 | 942 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' | | jhl_master-mysql-bin.000011 | 942 | Query | 11701 | 1063 | use `jhl`; create table t3(id int primary key)engine=myisam | | jhl_master-mysql-bin.000011 | 1063 | Gtid | 11701 | 1124 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5' | | jhl_master-mysql-bin.000011 | 1124 | Query | 11701 | 1232 | use `jhl`; create table t4(id int primary key) | | jhl_master-mysql-bin.000011 | 1232 | Gtid | 11701 | 1293 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6' | | jhl_master-mysql-bin.000011 | 1293 | Query | 11701 | 1365 | BEGIN | | jhl_master-mysql-bin.000011 | 1365 | Table_map | 11701 | 1405 | table_id: 112 (jhl.t4) | | jhl_master-mysql-bin.000011 | 1405 | Write_rows | 11701 | 1441 | table_id: 112 flags: STMT_END_F | | jhl_master-mysql-bin.000011 | 1441 | Xid | 11701 | 1468 | COMMIT /* xid=105 */ | +-----------------------------+------+----------------+-----------+-------------+-------------------------------------------------------------------+
需要关注以下3行
BEGIN View_change <----> view_id=15294216022242634:1 COMMIT
组复制中，每个决策都需要组中大多数节点达成一致，包括新节点加组、离组的决定。实际上，组复制中内置了一个组成员服务，这个服务负责组成员的配置以及动态捕获组中成员列表，这个成员列表成为成员视图。每个视图都有一个view id，view id的第一部分是创建组时随机生成的，只要组不停止，这部分就不改变，第二部分是从1开始的单调递增的数值。每当有成员加组、离组时，都会触发这个服务对组成员进行重新配置，每次组成员的重新配置，view id的第二部分都会单调递增地加1，表示这是新的成员视图，新的组成员视图需要得到组中大多数节点的同意，所以这个消息要在组中进行传播。如何传播？就是通过将视图更改的事件作为一个事务写进binlog中，然后在组中到处复制，这样每个节点都可收到视图变化的消息，并对此做出回应，同意之后再commit这个事务。如果足够细心，会发现这个事务的提交和下面插入数据的提交(COMMIT /* xid=63 */)方式不一样。如果不理解也没关系，这个理论并不影响组复制的使用。
再仔细一看，还可以发现MySQL中的DDL语句是没有事务的。所以，绝不允许不同节点上对同一个对象并发执行"DDL+DML"和"DDL+DDL"，冲突检测机制会探测到这样的冲突。
添加第二个节点
配置文件和节点一类似
datadir=/data socket=/data/mysql.sock server-id=11701 # 必须 gtid_mode=on # 必须 enforce_gtid_consistency=on # 必须 log-bin=/data/master-bin # 必须 binlog_format=row # 必须 binlog_checksum=none # 必须 master_info_repository=TABLE # 必须 relay_log_info_repository=TABLE # 必须 relay_log=/data/relay-log # 必须，如果不给，将采用默认值 log_slave_updates=ON # 必须 sync-binlog=1 # 建议 log-error=/data/error.log pid-file=/data/mysqld.pid
#MGR transaction_write_set_extraction=XXHASH64 loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" loose-group_replication_start_on_boot=off loose-group_replication_member_weigth = 20 loose-group_replication_local_address="10.16.208.4:26005" loose-group_replication_group_seeds="10.16.208.5:26005,10.16.208.4:26005"
这里和s1的配置文件相比，只修改了server-id和group_replication_local_address以及权重值。
change master to
master_user='repl',
master_password='P@ssword1!'
for channel 'group_replication_recovery';
这时，就已经选择好donor，并和donor建立通道连接了。如果去s1上查看，可以看到这个通道的连接。下面的查询结果中，第二行就是和s2建立的连接，通道为group_replication_recovery。
(root@g1-db-test-v06:6005)[(none)]>select * from mysql.slave_master_infoG
*************************** 1. row ***************************
Number_of_lines: 25
Master_log_name: jhl_master-mysql-bin.000011
Master_log_pos: 1468
Host: 10.16.208.5
User_name: dmrepl
User_password: hn%u0)M9
Port: 6005
Connect_retry: 60
Enabled_ssl: 0
Ssl_ca:
Ssl_capath:
Ssl_cert:
Ssl_cipher:
Ssl_key:
Ssl_verify_server_cert: 0
Heartbeat: 30
Bind:
Ignored_server_ids: 0
Uuid: b3f6377f-52c5-11ea-92c4-be6f2b61965c
Retry_count: 86400
Ssl_crl:
Ssl_crlpath:
Enabled_auto_position: 1
Channel_name:
Tls_version:
*************************** 2. row ***************************
Number_of_lines: 25
Master_log_name:
Master_log_pos: 4
Host:
User_name: dmrepl
User_password: hn%u0)M9
Port: 3306
Connect_retry: 60
Enabled_ssl: 0
Ssl_ca:
Ssl_capath:
Ssl_cert:
Ssl_cipher:
Ssl_key:
Ssl_verify_server_cert: 0
Heartbeat: 0
Bind:
Ignored_server_ids: 0
Uuid:
Retry_count: 86400
Ssl_crl:
Ssl_crlpath:
Enabled_auto_position: 0
Channel_name: group_replication_recovery
Tls_version:
安装组复制插件,启动组复制功能
install plugin group_replication soname 'group_replication.so';
(root@g1-db-test-v06:6005)[(none)]>start group_replication; ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.
最后发现是一个参数没有改
binlog_checksum=none
然后启动,还是报错
突然想到这个从库之前有单独做过一些操作,GTID和主库不一致,比主库多
然后将GTID重新设置为主库的gtid集合
(root@g1-db-test-v06:6005)[(none)]>set global gtid_purged='6a3aff53-6516-11e9-adbc-6c0b84be13e4:1-12,b3f6377f-52c5-11ea-92c4-be6f2b61965c:1-6';
再启动,就没问题了,具体细节以后再研究
(root@g1-db-test-v06:6005)[(none)]>start group_replication; Query OK, 0 rows affected (4.68 sec)
----------------------------
参考wiki: