MYSQL--架构--MGR--理论--03--要求和限制

MYSQL–架构–MGR–理论–03–要求和限制

---

1、MGR要求

1.1、基础结构

1.1.1、InnoDB 存储引擎

1. 数据必须存储在InnoDB事务存储引擎中。
2. 事务以乐观方式执行，然后在提交时检查冲突，如果存在冲突，为了保持整个组的一致性，一些事务将被回滚。 这意味着需要事务存储引擎。
3. InnoDB还提供了一些附加功能，可以在与Group Replication一起操作时更好地管理和处理冲突。

1.1.2、主键

1. 每个表必须具有已定义的主键或等效的主键，其中等效项是非null唯一键。
2. 这些key需要作为表中每一行的唯一标识符，因为在进行事务冲突检测时需要利用主键值对比。

1.1.3、IPV4 网络

1. 组通信引擎仅支持IPv4,因此，组复制需要IPv4网络基础结构
2. 不支持IPv6

1.1.4、网络性能

MGR节点间网络延迟尽量小，要避免跨网络部署

1.2、服务器实例配置

必须在作为组成员的服务器实例上配置以下选项。

1.2.1、Binary Log Active

1. 设置–log-bin [= log_file_name]。
2. MGR复制二进制日志内容，因此二进制日志需要打开才能运行。
3. 默认情况下启用此选项。

1.2.2、Slave Updates Logged

1. 设置–log-slave-updates=on
2. 服务器需要记录通过复制应用程序应用的二进制日志。组中的服务器需要记录他们收到的所有事务并从组中应用。 这是必需的，因为恢复是通过依赖组中的参与者的二进制日志来进行的。 因此，每个事务的副本都需要存在于每个服务器上，即使对于那些未在服务器本身上启动的事务也是如此。

1.2.3、二进制日志行格式

1. 设置–binlog-format = row。
2. 组复制依赖于基于行的复制格式，以在组中的服务器之间一致地传播更改。 它依赖于基于行的基础结构来提取必要的信息，以检测在组中不同服务器中并发执行的事务之间的冲突

1.2.4、全局事务标识符 ON

1. 设置–gtid-mode = ON。
2. 组复制使用全局事务标识符来准确跟踪在每个服务器实例上已提交的事务，从而能够推断哪些服务器执行的事务可能与其他地方已提交的事务冲突。 换句话说，显式事务标识符是框架的基本部分，以便能够确定哪些事务可能冲突。

1.2.5、复制信息存储库。

1. 设置–master-info-repository = TABLE和–relay-log-info-repository = TABLE。
2. 复制应用程序需要将主信息和中继日志元数据写入mysql.slave_master_info和mysql.slave_relay_log_info系统表。 这可确保组复制插件具有一致的可复制性和复制元数据的事务管理。

1.2.6、事务写集提取

设置–transaction-write-set-extraction = XXHASH64，以便在收集行以将它们记录到二进制日志时，服务器也会收集写入集。 写集基于每行的主键，是标记的简化和紧凑视图，唯一标识已更改的行。 然后，此标记用于检测冲突。

1.2.7、多线程应用

1. 组复制成员可以配置为多线程应用程序，从而可以并行应用事务。

   1. 设置–slave-parallel-workers = N(其中N是并行应用程序线程的数量)，
   2. 设置 - slave-preserve-commit-order = 1，以及–slave-parallel-type = LOGICAL_CLOCK。

2. 设置–slave-parallel-workers = N启用成员上的多线程应用程序。组复制依赖于保证所有参与成员以相同顺序接收和应用已提交事务的一致性机制，因此您还必须设置–slave-preserve-commit-order = 1以确保并行事务的最终提交是与原始事务的顺序相同。最后，为了确定哪些事务可以并行执行，中继日志必须包含使用–slave-parallel-type = LOGICAL_CLOCK生成的事务父信息。在不设置其他两个选项的情况下将–slave-parallel-workers设置为大于0的时，尝试添加成员，会生成错误并阻止实例加入。

1.3、关闭二进制日志校验和(–binlog-checksum=NONE )

1.4、隔离级别设置为RC

2、MGR限制

2.1、不支持复制事件 checksums

由于复制事件校验和的设计限制，组复制当前无法使用它们。 因此设置–binlog-checksum = NONE。

2.2、不支持间隙锁

1. 认证过程没有考虑间隙锁定，因为InnoDB之外没有关于间隙锁定的信息。
2. 隔离级别需设置为read_committed；

2.3、不支持表锁和名称锁

1. 认证过程不考虑表锁或命名锁
2. 不支持对表进行锁操作(lock /unlock table),不会发送到其他节点执行 ,影响需要对表进行加锁操作的情况，列入mysqldump全表备份恢复操作

2.4、不支持SERIALIZABLE 隔离级别

默认情况下，多主模式不支持SERIALIZABLE隔离级别。 将事务隔离级别设置为SERIALIZABLE会使组复制配置为拒绝提交事务

2.5、不支持并发DDL与DML操作

使用多主模式时，不支持针对同一对象但在不同服务器上执行的并发DDL和DML。

2.6、不支持具有级联约束的外键

多主模式组(所有配置为group_replication_single_primary_mode = OFF的成员)不支持具有多级外键依赖关系的表，特别是具有已定义CASCADING外键约束的表。

这是因为导致多主模式组执行级联操作的外键约束可能导致未检测到的冲突，并导致组成员之间的数据不一致。 因此，我们建议在多主模式组中使用的服务器实例上设置group_replication_enforce_update_everywhere_checks = ON，以避免未检测到的冲突。

在单主模式下，这不是问题，因为它不允许并发写入组的多个成员，因此不存在未检测到的冲突的风险。

2.7、不支持大事务

事务大小最好不超过143MB，当事务过大，无法在5 秒的时间内通过网络在组成员之间复制消息，则可能会怀疑成员失败了，然后将其驱逐出局。

2.8、不支持 MyISAM 表

2.9、多主模式死锁

多主模式运行时，SELECT … FOR UPDATE语句可能导致死锁。 这是因为锁不在组的成员之间共享，因此可能无法达到对此类语句的期望。

2.10、复制过滤

复制筛选器不能在 服务器实例上使用，因为在某些服务器上筛选事务会使组无法就一致状态达成协议。

2.11、MGR集群节点不能超过9,超过9台无法加入集群

2.12、RP和普通复制binlog校验不能共存

1. 设置–binlog-checksum=none；

2.13、DDL语句不支持原子性，不能检测冲突，执行后需自行校验是否一

2.14、在多主模式中，会进行下列检查

1. 如果事务在SERIALIZABLE隔离级别下执行，则在与组同步时其提交失败。
2. 如果事务针对具有级联约束的外键的表执行，则在与组同步时事务无法提交。

2.14.1、取消上面检查

group_replication_enforce_update_everywhere_checks=FALSE

1. 通过将选项group_replication_enforce_update_everywhere_checks设置为FALSE，可以取消激活这些检查。
2. 在单主模式下部署时，此选项必须设置为FALSE。