MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供。MGR基于分布式paxos协议，实现组复制，保证数据一致性。内置故障检测和自动选主功能，只要不是集群中的大多数节点都宕机，就可以继续正常工作。提供单主模式与多主模式，多主模式支持多点写入。MGR集群的搭建，参考文章MySQL MGR 集群搭建（单主模式&多主模式）。

相对于传统的MySQL，MGR带来的改进让人激动人心，但是使用MGR也有一些前提条件与注意事项，下面基于 MySQL 8.0.11 版本进行简单说明。

一、MGR使用限制

1. 仅支持innodb存储引擎
   MGR集群中，只支持innodb存储引擎，能够创建非innodb引擎的表，但是无法写入数据，向非innodb表写数据直接报错。

mysql> create table tb_myisam(id int, name varchar(50), primary key(id)) engine=myisam;
Query OK, 0 rows affected (0.05 sec)
mysql> insert into tb_myisam select 1, '1';
ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

1. 表必须有主键，或者非Null的唯一键
   MGR集群中，只支持innodb引擎的表，并且该表必须有显式的主键，或者非Null的唯一键，否则即使能够创建表，也无法向表中写入数据。

# 创建没有主键的表，写入数据失败
mysql> create table tb_no_primary_key(name varchar(50));
Query OK, 0 rows affected (0.15 sec)
mysql> insert into tb_no_primary_key select '1';
ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

# 创建Null唯一索引的表，写入数据失败
mysql> create table tb_null_unique_key(name varchar(50), unique key(name));
Query OK, 0 rows affected (0.09 sec)
mysql> insert into tb_null_unique_key select '1';
ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

# 创建非Null唯一索引的表，写入数据成功
mysql> create table tb_no_null_unique_key(name varchar(50) not null, unique key(name));
Query OK, 0 rows affected (0.04 sec)
mysql> insert into tb_no_null_unique_key select '1';
Query OK, 1 row affected (0.06 sec)
Records: 1  Duplicates: 0  Warnings: 0

1. 网络限制
   MGR 组通信引擎目前仅支持IPv4网络，并且对节点间的网络性能要求较高，低延迟、高带宽的网络是部署MGR集群的基础。
2. MGR忽略表锁和命名锁，在MGR中lock tables、unlock tables、get_lock、release_lock等这些表锁和命名锁将被忽略。
3. MGR多主模式中，默认不支持 SERIALIZABLE 隔离级别。
4. 多主模式下，对同一个对象进行并发的有冲突的ddl和dml操作导致这种冲突在部分成员节点中无法检测到，最终可能导致数据不一致。
5. 多主模式下，不支持级联约束的外键，可能造成有冲突的操作无法检测。
6. 不支持超大事务。
7. 多主模式下可能导致死锁，比如select ...for update在不同节点执行，由于多节点锁无法共享，很容易导致死锁。
8. 不支持复制过滤，如果有节点设置了复制过滤，将影响节点间决议的达成。
9. MGR最多支持9个节点，大于9个节点，将拒绝新节点的加入。

二、节点配置要求

• log_bin
• log_slave_updates
• binlog_format=ROW
• gtid_mode=ON
• master_info_repository=TABLE
• relay_log_info_repository=TABLE
• transaction_write_set_extraction=XXHASH64
• 并行复制
  • slave_parallel_type=LOGICAL_CLOCK
  • slave_preserve_commit_order=1
  • slave_parallel_workers=[N]
• binlog_checksum=NONE
• transaction_isolation=READ-COMMITTED #官方推荐在MGR中隔离级别设置为RC

三、MGR冲突检测

MGR多主模式下，一个事务在执行时，并不会做前置的检查，但是在提交阶段，会和其他节点通信对该事务是否能够提交达成一个决议。在多个节点同对相同记录的修改，在提交时会进行冲突检测，首先提交的事务将获得优先权。例如对同一条记录的修改，t1事务先于t2事务，那么t1事务在冲突检测后获得执行权，顺利提交，而t2事务进行回滚。显然这种多点写入条件下，对于同一条记录的并发修改，由于大量的回滚，导致性能很低，因此MySQL官方建议，这种对于同一条记录的修改，应该放在同一个节点执行，这样可以利用节点本地锁来进行同步等待，减少事务回滚，提高性能。

四、MGR新节点加入过程

MGR中，新节点申请加入组，会在组中生成一个View_change事件，组内所有online节点将该事件写入到binlog，同时，申请加入组的新节点也会记录这个View_change事件，之后，该节点会进入下面两个阶段。

• 第一阶段，新节点会从组内online的节点中选择一个作为贡献者(donor)，通过标准的异步复制通道，拉取贡献者的binlog，并应用这些binlog。与此同时，新节点也会获取当前组内正在交换的事务信息，并将其缓存到队列中，当binlog应用完成，也就是应用到View_change事件处，异步复制通道关闭，进入第二阶段。
• 第二阶段，新节点处理缓存在队列中的组内事务信息，当队列中的事务信息处理完成，即缓存队列长度为0时，新节点在组内状态变为online。

在第一阶段，遇到任何错误，新节点会自动从组内选择另外一个online节点作为贡献者，如果仍然遇到异常，会继续选择其他online节点，直到所有online节点枚举完毕，如果这时仍然报错，会sleep一段时间之后，再次重试，sleep时间和重试次数通过相应参数来控制。

第一阶段，应用binlog的开始点由新节点的gtid_executed决定，结束点由View_change事件决定。MGR新节点加入组的第一阶段，由于使用传统的异步binlog数据同步，如果新加入的节点使用较早的备份，可能出现binlog接不上的情况，新节点一直处于RECOVERING状态，在经过一定时间间隔和一定次数的重试后，恢复失败，新节点从组中退出。另外一种情况，binlog能够接上，但是binlog太多，导致应用binlog时间太长，同时第二阶段缓存队列也可能变得很大，整个恢复过程也将花费太长的时间。因些建议新节点加入组时，使用最近、最新的一次完整备份数据作为基础。

下面附上View_change事件信息和binlog接不上的报错信息。

View_change事件信息：

mysql> show binlog events;
+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name         | Pos | Event_type     | Server_id | End_log_pos | Info                                                               |
+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| mysql-bin.000003 |   4 | Format_desc    |         1 |         124 | Server ver: 8.0.11, Binlog ver: 4                                  |
| mysql-bin.000003 | 124 | Previous_gtids |         1 |         191 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-18                          |
| mysql-bin.000003 | 191 | Gtid           |         1 |         269 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:19' |
| mysql-bin.000003 | 269 | Query          |         1 |         331 | BEGIN                                                              |
| mysql-bin.000003 | 331 | View_change    |         1 |         470 | view_id=15313080985527991:9                                        |
| mysql-bin.000003 | 470 | Query          |         1 |         538 | COMMIT                                                             |
| mysql-bin.000003 | 538 | Gtid           |         1 |         616 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:20' |
| mysql-bin.000003 | 616 | Query          |         1 |         678 | BEGIN                                                              |
| mysql-bin.000003 | 678 | View_change    |         1 |         817 | view_id=15313080985527991:11                                       |
| mysql-bin.000003 | 817 | Query          |         1 |         885 | COMMIT                                                             |
+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
10 rows in set (0.00 sec)

binlog接不上报错信息

 

转载：https://www.jianshu.com/p/4700e4272413