MySQL组复制的要求和限制归纳

组复制的要求: 1).InnoDB存储引擎：数据必须存储在事务型的InnoDB存储引擎中。事务以乐观形式执行，然后在提交前会检测冲突问题。如果有冲突，为了维护组中一致性，有些事务必须回滚。这意味着需要事务型的存储引擎。此外，InnoDB 存储引擎提供了一些额外的功能，它们结合组复制时能更好地管理和处理冲突。 2).Primary Keys：每张需要被组复制的表都必须显式定义一个主键。主键在判断事务是否冲突扮演极其重要的角色：通过主键来准确识别每个事务中修改了表中的哪些行。(实际上是将主机hash成写集，然后由certifier来并发事务之间的检测冲突性) 3).使用IPv4 地址：MySQL组复制使用的组通信引擎组件只支持 IPv4。因此，必须使用IPv4的网络。 4).良好的网络性能：组复制设计的初衷是部署在集群环境中，集群中的节点相互之间都非常近，因此除了网络延迟，网络带宽也会影响组复制。 组复制的限制： 1).Replication Event Checksums：由于对复制事件校验的设计缺陷，目前组复制不能使用它们。因此，需要设置--binlog-checksum=NONE。 2).Gap Locks：在验证阶段中(certification process)，不会考虑 Gap Locks，因此在 InnoDB 的外部无法获取任何关于Gap 锁的信息。 注意:除非你的应用程序或业务需求依赖于REPEATABLE READ(MySQL默认该隔离级别)，否则建议在组复制中使用READ COMMITTED隔离级别。在READ COMMITTED隔离级别中，InnoDB基本上不会使用Gap Locks，这将使得InnoDB自带的冲突探测能和组复制的冲突探测相互对齐从而保持一致。 3).Table Locks and Named Locks：验证阶段(certification process)中不考虑表锁和命名锁(见get_lock())。 4).不支持 SERIALIZABLE 隔离级别：在多主模型下，默认不支持该隔离级别。如果在多主模型下设置了该隔离级别，将拒绝提交事务。 5).不支持并发的 DDL 和 DML 操作：不支持在多主模型下不同节点上同时执行DDL和DML修改同一对象。在某节点上对某对象执行DDL语句时，如果在其他节点同时执行DML修改该对象，将有一定风险探测到冲突。(译注：是 DDL+DML 的并发，DDL+DDL 的并发也不允许。这是因为MySQL中没有DDL事务，不能保证DDL的原子性，当DDL和DML同时操作某一个对象，可能DDL修改后，DML将因为对象结构的改变而无法执行，继而回滚) 6).不支持级联的外键约束：多主模型的组(所有节点都配置了group_replication_single_primary_mode=OFF)不支持多级外键依赖，特别是表上定义了级联的外键约束(CASCADING foreign key constraints)。这是因为多主模型下执行外键约束的级联操作可能会出现未检测到的冲突，从而导致组内成员间数据不一致。因此，我们推荐在使用多主模型时，在每个节点上都设置group_replication_enforce_update_everywhere_checks=ON以避免出现未检测到的冲突。在单主模型下没有这种问题，因为没有并发写操作，从而不可能会出现未被探测到的冲突。 7).大事务可能会错误：如果一个事务非常大，导致GTID的内容非常多，以至于无法在 5 秒内通过网络传输完成，这时组成员间的通信将失败。要避免该问题，可以尽可能地限制事务的大小。例如，将LOAD DATA INFILE的文件切割为多个小块。 8).多主模型可能出现死锁：在多主模型下，SELECT ... FOR UPDATE语句可能会导致死锁。这是因为组内成员之间不会共享锁资源(译注：share nothing)，因此这样的语句可能达不到预期的结果。