mysql mgr是否使用vip_MYSQL MGR模式注意事项

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

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

一、MGR使用限制

仅支持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.

表必须有主键，或者非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

网络限制MGR 组通信引擎目前仅支持IPv4网络，并且对节点间的网络性能要求较高，低延迟、高带宽的网络是部署MGR集群的基础。

MGR忽略表锁和命名锁，在MGR中lock tables、unlock tables、get_lock、release_lock等这些表锁和命名锁将被忽略。

MGR多主模式中，默认不支持 SERIALIZABLE 隔离级别。

多主模式下，对同一个对象进行并发的有冲突的ddl和dml操作导致这种冲突在部分成员节点中无法检测到，最终可能导致数据不一致。

多主模式下，不支持级联约束的外键，可能造成有冲突的操作无法检测。

不支持超大事务。

多主模式下可能导致死锁，比如select ...for update在不同节点执行，由于多节点锁无法共享，很容易导致死锁。

不支持复制过滤，如果有节点设置了复制过滤，将影响节点间决议的达成。

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