【MySQL 组复制】1.组复制技术简介

组复制有两种模式

单主模式(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_info\G
*************************** 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:

https://www.cnblogs.com/f-ck-need-u/p/9216828.html