Mysql组复制（MGR）——前提及限制

本文将对组复制的前提条件和限制进行列举和解释。

一.组复制前提

想用组复制的服务器实例必须满足如下前提条件：

1.基础架构

1）InnoDB存储引擎。数据必须存储于InnoDB事务存储引擎。事务被乐观执行，且提交时，检查冲突。如果有冲突，为了维护组内一致性，某些事务会被回滚。这意味着需要一个事务存储引擎。然而，InnoDB提供某些另外功能以与组复制一起操作时能更好管理和处理冲突。

2）主键。组复制的每张表必须有一个定义主键或主键等同物，这里，主键等同物为非空唯一键。需要该键作为表内每行数据的唯一标示符，以便使系统能通过识别每个事务已修改了哪些数据行来决定哪些事务发生冲突。

3）IPv4网络。Mysql组复制使用的组通信引擎仅支持IPv4。所以，组复制要求IPv4网络基础架构。

4）网络性能。组通信设计部署于服务器实例彼此距离很近的集群环境，且其被网络延迟和带宽所影响。

2.服务器实例配置

下述选项必须在组成员的服务器实例中配置。

1）二进制日志活动（Binary Log Active）。设置—log-bin[=log_file_name]。mysql组复制复制二进制日志内容，所以，二进制日志需要为其打开和操作。该选项默认为开启。

2）备库变更记录（Slave Updates Logged）。设置—log-slave-updates。服务器需要记录通过复制应用器应用的二进制日志。组内的服务器需要记录其从组收到和应用的所有事务。因为恢复依赖组内二进制日志形式的参与者实施，所以，需要这些日志。因此，每个事务的拷贝需要存在于每个服务器，甚至那些服务器本身未发起的那些事务。

3）二进制日志行格式。设置—binlog-format=row。组复制依赖于基于行的复制格式向组内服务器一致的广播变更。其依赖于基于行的基础架构能抽取必须要信息来探测组内不同服务器上并发执行的事务间的冲突。

4）打开全局事务标示符。设置—gtid-mode=ON。组复制用全局事务标示符精确跟踪哪个事务在每个服务器实例上已经提交，这样，能判断哪些服务器已经执行了可能与其他地方提交的事务冲突的事务。换句话说，显示事务标示符是能决定哪些事务也许提交的框架的一部分。

5）复制信息库。设置—master-info-repository=TABLE和—replaylog-info-repository=TABLE。复制应用器需要获取写入mysql.slave_master_info和mysql.slave_relay_log_info系统表中的主库信息和中继日志元数据。这确保组复制插件有复制元数据的一致性恢复和事务管理。

6）事务写集抽取。设置—transaction-write-set-extraction=XXHASH64，以便当将数据行收集记录到二进制日志时，服务器也收集写集。写集基于每个数据行的主键且被简化，并将唯一标识变更数据行标签的视图打包压缩。该标签接着用于探测冲突。

7）多线程应用器。组复制成员能被配置为多线程应用器，使事务能并行的应用。设置设置—slave-parallel-workers=N（这里N为并行应用器线程数），—slave-preserve-commit-order=1，和—slaveparallel-type=LOGICAL_CLOCK。设置—slave-parallel-workers=N开启成员上的多线程应用器。组复制依赖于基于所有参与成员按照同样顺序接收和应用提交事务的保证构建的一致机制，因此，您必须也设置—slave-preserve-commit-order=1来确保并发事务作为原始事务按照同样顺序最终提交。最终，为了决定哪些事务能并发执行，中继日志必须包含—slave-parallel-type=LOGICAL_CLOCK产生的事务父信息。以—slave-parallel-workers设置为大于0的值而不设置另外两个选项的试图会产生错误且阻止实例加入。

二．组复制限制

已知组复制有下列限制。

--注：

       1）组复制基于GTID为基础的复制构建，所以，您也应该了解基于GTID复制的限制。

1）复制事件校验和。由于复制事件校验和的设计限制，组复制目前不能使用它们。因此，设置—binlog-checksum=NONE。

2）间隙锁（Gap Locks）。认证过程不会考虑间隙锁，因为间隙锁相关信息在InnoDB外不可用。

--注：

        1）除非您的应用依赖于repeatable read语义，否则，我们推荐组复制使用read committed隔离级别。InnoDB在read committed中并不使用间隙锁，这将使InnoDB内的本地冲突探测与组复制执行的分布式冲突探测保持一致。

3）表锁和命名锁。认证过程并不考虑表所或命名锁。

4）串行（seriablizable）隔离级别。多主复制组默认不支持串行隔离级别。复制组内将一个事务隔离级别设置为seriablizable使得该事物不可提交。

5）并发DDL与DML操作。当用多主模式时，同一对象但不同服务器上执行的并发数据定义语句和数据操作语句不被支持。一个对象上数据定义语句执行期间，在同一对象但不同服务器实例上并发执行的数据操作语句存在与不同实例上执行数据定义语句冲突而不被探测到的风险。

6）层级约束的外键。多主模式组（成员都配置group_replication_single_primary_mode=OFF）不支持多级外键依赖，特别是定义了cascading外键约束的表。这是因为多主模式组执行的导致层级操作的外键约束能导致不可探测的约束及组成员间数据不一致。因此，我们推荐将多主模式组中使用的服务器实例的group_replication_enforce_update_everywhere_checks=ON以避免未被探测的冲突。

单主模式中，由于其不允许并发向组的多个成员写，因此，这不是问题且没有不被探测冲突的风险。

7）巨大的事务。导致GTID内容大得在5秒时间窗内不能通过网络在组成员间拷贝的单个事务，能引起组通信失败。为了避免该问题，尝试尽可能限制事务的大小。例如：将load data infile用的文件拆分成较小的块。

8）mysql enterprise audir和mysql enterprise firewall。5.7.21版本前，mysql enterprise audit和mysql enterprise firewall在mysql系统数据库中使用myisam表。组复制并不支持myisam表。

9）多主模式死锁。当组以多主模式操作时，select … for update语句能导致死锁。这是因为该锁在组成员间不共享，所以，这种语句的目标不会达成。