MySQL Group Replication(MGR)使用限制

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

发表评论