MySQL Group Replication(MGR)使用限制

MySQL / 作者：

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

相对于传统的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时间太长，同时第二阶段缓存队列也可能变得很大，整个恢复过程也将花费太长的时间。建议新节点加入组时，使用最近、最新的一次完整备份数据作为基础。

发表评论