17.7 需求和限制

2020-05-11 11:20:54

参考官方文档：
https://dev.mysql.com/doc/refman/5.7/en/group-replication-requirements-and-limitations.html

17.7.1 组复制需求
要用于组复制的服务器实例必须满足以下要求。

基础结构

InnoDB 存储引擎

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

主键

要由组复制的每个表必须具有已定义的主键或等效的主键，其中等效项是非null键。这些key需要作为表中每一行的标识符，使系统能够通过准确识别每个事务已修改的行来确定哪些事务冲突。
IPV4 网络

MySQL Group Replication使用的组通信引擎仅支持IPv4。因此，组复制需要IPv4网络基础结构

网络性能

组复制旨在部署在服务器实例彼此非常接近的集群环境中，并受网络延迟和网络带宽的影响。

服务器实例配置

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

Binary Log Active

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

Slave Updates Logged

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

二进制日志行格式

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

全局事务标识符 ON

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

复制信息存储库。

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

事务写集提取

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

多线程应用

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

17.7.2 组复制限制

组复制存在以下已知限制。请注意，针对多主模式组所描述的限制和问题也可以在故障转移事件期间应用于单主模式群集，而新选择的主数据库则从旧主数据库中刷新其应用程序队列。

TIP：
组复制基于基于GTID的复制，因此您还应了解第16.1.3.6节“使用GTID进行复制的限制”。

复制事件 checksums

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

间隙锁

认证过程没有考虑间隙锁定，因为InnoDB之外没有关于间隙锁定的信息。有关详细信息，请参阅Gap Locks。

注意：
除非您在应用程序中依赖REPEATABLE READ语义，否则我们建议将READ COMMITTED隔离级别与Group Replication一起使用。 InnoDB在READ COMMITTED中不使用间隙锁，它将InnoDB中的本地冲突检测与Group Replication执行的分布式冲突检测对齐。

表锁和名称锁

认证过程不考虑表锁（请参见第13.3.5节“LOCK TABLES和UNLOCK TABLES语法”）或命名锁（请参阅GET_LOCK（））

SERIALIZABLE 隔离级别

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

并发DDL与DML操作

使用多主模式时，不支持针对同一对象但在不同服务器上执行的并发DDL和DML。在对象上执行数据定义语言（DDL）语句期间，在同一对象上但在不同服务器实例上执行并发数据操作语言（DML）存在在未检测到的不同实例上执行DDL冲突的风险。

具有级联约束的外键

多主模式组（所有配置为group_replication_single_primary_mode = OFF的成员）不支持具有多级外键依赖关系的表，特别是具有已定义CASCADING外键约束的表。这是因为导致多主模式组执行级联操作的外键约束可能导致未检测到的冲突，并导致组成员之间的数据不一致。因此，我们建议在多主模式组中使用的服务器实例上设置group_replication_enforce_update_everywhere_checks = ON，以避免未检测到的冲突。

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