20.3组复制要求与限制

​

20.3.1 组复制的要求

需要配置组复制的实例需要满足以下要求：

infrastructure

innodb存储引擎

数据必须存储在innodb事务型的存储引擎上。事务执行是乐观的(默认情况是认为执行成功的)，然后再提交的时候进行冲突检测。如果有事务冲突，为了维护组中的一致性，冲突的事务会被回滚。这就意味着需要事务型存储引擎。当事务并发执行时innodb会提供一些函数更好的管理事务冲突。使用其他的存储引擎，包括临时的MEMORY存储引擎，组复制可能会导致报错。可以通过disabled_storage_engines参数禁用其他的存储引擎防止这些问题。比如：

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

主键

组内复制的每个表都必须定义一个主键，或者类似主键的约束(比如非空的唯一约束)。这种key会唯一标识表中的每一个行，启用主键或者唯一约束可以精确的判断每一个事物中被修改的行从而进行判断那些事务有冲突。组复制中有自己内置的主键或者主键等价的(唯一约束)的检查，所以无需使用sql_require_primary_key系统变量进行检查。可以在组复制运行期间执行set sql_require_primary_key=on,也可以对Group Replication 通道在执行change replication source to或者change master to语句的时候打开require_table_primary_key选项。然而你需要意识到，在组复制的内置检查下被允许的一些事务，在设置了sql_require_primary_key=ON或REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON时可能不被允许。

sql_require_primary_key：在创建表或者修改表结构的时候强制要求表有一个主键

REQUIRE_TABLE_PRIMARY_KEY_CHECK：是 MySQL 复制（特别是组复制）中的一个选项，用于控制是否要求复制的表具有主键（或等效的非空唯一键）。这个选项可以在配置复制源（CHANGE REPLICATION SOURCE TO，在 MySQL 8.0+ 中）或主服务器（CHANGE MASTER TO，在较旧的版本中）时设置,

与 sql_require_primary_key 系统变量不同，REQUIRE_TABLE_PRIMARY_KEY_CHECK 选项仅针对特定的复制通道（或主服务器）进行设置，而 sql_require_primary_key 则影响整个 MySQL 服务器实例。
REQUIRE_TABLE_PRIMARY_KEY_CHECK，取值{STREAM | ON | OFF}，默认值为STREAM。

当设置为ON时，强制检查主键。

当设置为OFF时，不检查主键。
当设置为STREAM时，根据主库复制过来的配置来决定要不要检查主键。

网络性能

MGR用来部署集群环境，server实例之间彼此非常接近。网络的延迟和贷款影响组复制的性能和稳定，在所有的组成员之间必须确保双向的网路连通性。如果某些server实例的入站或者出站被阻塞(比如：防火墙，或者网络连接中的问题)，那么组成员就无法在组中运行，并且组成员(包括有问题的成员)可能不回去报告或者正确显示受影响的成员状态。

从MySQL8.0.14开始，你可以使用IPV4或者IPV6，也可以混合使用。用于远程组复制server的TCP通信。没有什么能阻止组复制在虚拟私人网络（VPN）上运行。

也是从MySQL8.0.14开始，当组复制服务器实例位于同一位置并共享本地组通信引擎（XCom）实例时，会使用具有较低开销的专用输入通道进行通信，而不是使用TCP套接字。对于某些需要远程XCom实例之间通信的组复制任务（如加入组），仍然使用TCP网络，因此网络性能会影响组的性能。

server实例的配置

如下是组成员中的server实例必须配置的参数选项：

Unique Server Identifier

在复制拓扑架构(即主从复制，组复制，级联复制等)中要求使用server_id可以唯一标识一个MySQL实例。server id必须是1到(2^32)-1这个范围的正整数，而且必须在复制的拓扑结构中与其他的实例不同。

Binary Log Active

设置–log-bin[=log_file_name]。从MySQL8.0开始，binlog是默认启用的，不需要指定这个参数除非需要自己手动指定binlog文件的名称。组复制会复制binlog中的内容，所以必须开启binlog。

Replica Update Logged

set log_replica_updates=on(从MySQL8.0.26开始)或者set log_slave_update=on(在MySQL8.0.26之前)。从MySQL8.0开始，这个设置是默认的，不需要指定。组内的成员需要记录它们在加入时从捐赠者(事务发起者)那里接收到的事务，并通过复制应用器(applier)应用这些事务，同时记录它们从组中接收并应用的所有事务。这使得组复制能够通过从现有组成员的二进制日志中进行状态传输来进行分布式恢复。

Binary Log Row Format

设置binlog_format=row。这个设置是默认的，无需指定。组复制是基于RBR(row-base replication)在组中传播数据的变化，并且准确的探测在组中并发事务的冲突信息。从MySQL8.0.19开始，组复制通道自动田家庵require_row_fowmat设置以启用事务应用时是基于row模式的复制。

Binary Log Checksums Off

Binary Log Checksums Off(一直到MySQL8.0.20)，在MySQL8.0.20以前包括8.0.20.binlog_checksum=NONE.在这些版本中组复制是不能使用checksum的，并且不支持将这些checksum校验信息写入binlog当中，从MySQL8.0.21开始，组复制开始支持checksum，所有组复制可能使用的默认设置binlog_checksum=CRC32,无需指定,可以按照需求修改。

GLOBAL Transaction Identifiers On

set gtid_mode=on和enforce_gtid_consistency=on.这些设置不是默认的。组复制要求是基于GTID的复制，这样就可以通过全局的事务标识符去跟踪组中所有实例中已提交的事务。

Replication Information Repositories

设置master_info_repository=TABLE和relay_log_info_repository=TABLE.在MySQL8.0中，这些设置是默认的，这两个参数等于FILE的选项已经被废弃。从MySQL 8.0.23开始，使用这些系统变量本身也被认为是过时的，因此可以省略这些系统变量，仅使用默认值。复制应用器需要将复制元数据写入mysql.slave_master_info和mysql.slave_relay_log_info系统表，以确保组复制插件具有一致的恢复能力和复制元数据的事务管理。

Transaction Write Set Extraction

设置transaction_write_set_extraction=XXHASH64是为了在服务器收集行以记录到二进制日志时，同时收集write set。在MySQL 8.0中，这个设置是默认的，但从MySQL 8.0.26开始，使用这个系统变量被标记为过时。write set是基于每行的主键的，并且是唯一标识已更改行的标签的简化且紧凑的视图。组复制使用这些信息在所有组成员上进行冲突检测和验证.

Default Table Encryption

所有组成员的default_table_encryption必须设置同一个值。默认的schema或者tablespace要么都是on，要么都是off，默认是off。

Lower Case Table Names

所有组成员都必须设置lower_case_table_names相同的参数值，将其设置为1对于使用InnoDB存储引擎是正确的，而InnoDB存储引擎是组复制所必需的。请注意，此设置并非所有平台的默认设置。

Binary Log Dependency Tracking

将参数binlog_transaction_dependency_tracking设置为WRITESET可以提升组成员的性能，取决于组的负载。虽然在从relay log中应用事务的时候，在验证后会自己并行执行。这个与binlog_transaction_dependency_tracking设置的值无关，但这个值确实会影响事务如何写入组复制成员的二进制日志。这些日志中的依赖信息用于协助从捐赠者(事务发起的实例产生的binlog或者组中已存在的成员中)的二进制日志中进行分布式恢复，这个过程会在成员加入或重新加入组时发生。

binlog_transaction_dependency_tracking:
控制事务依赖模式，让从库根据主库写入binlog中的 commit timestamps 或者 write sets 并行回放事务（引入该参数之后，binlog的格式记录的内容中增加了时间戳和write sets信息）。
有三个取值：

COMMIT_ORDERE：使用 5.7 本来就支持的Group commit 的方式决定事务依赖
WRITESET：使用 WriteSet 的方式决定判定事务直接的冲突，发现冲突则依赖冲突事务，否则按照 COMMIT_ORDERE 方式决定依赖
WRITESET_SESSION：在 WRITESET 方式的基础上，保证同一个 session 内的事务不可并行
以上解释引用于：

https://www.cnblogs.com/gaogao67/p/14643635.html

binlog_transaction_dependency_tracking_binlog-transaction-dependency-tracking-CSDN博客

COMMIT_ORDERE

使用 5.7 本来就支持的Group commit 的方式决定事务依赖

WRITESET

使用 WriteSet 的方式决定判定事务直接的冲突，发现冲突则依赖冲突事务，否则按照 COMMIT_ORDERE 方式决定依赖
WRITESET_SESSION：在 WRITESET 方式的基础上，保证同一个 session 内的事务不可并行

 当replica_preserve_commit_order=on，将binlog_transaction_dependency_tracking设置为WRITESET和将他WRITESET_SESSIO有相同的效果。

Multithreaded Appliers

组成员可以被配置为多线程复制，启用事务进行并行回放的功能。从MySQL8.0.27开始，所有的副本(从库)都默认的被配置为多线程。启用多线程回访需要将replica_parallel_workers(从MySQL8.0.26开始)或者slave_parallel_workers(从MySQL8.0.26之前)设置为非零值即可。从MySQL8.0.27开始默认开启4个并行回放线程。最高可以指定1024个并行回放的线程。对于多线程复制需要做如下配置，从MySQL8.0.27开始如下的值都是默认值：

replica_preserve_commit_order=ON(从MySQL8.0.26开始)或者slave_preserve_commit_order=ON(MySQL8.0.26之前)

这个设置用来确保并行事务最终提交的顺序和发起事务的顺序一致。Group Replication 依赖于基于确保所有参与成员以相同顺序接收和应用已提交事务的一致性机制。

replica_parallel_type=LOGICAL_CLOCK(从MySQL8.0.26)或者slave_parallel_type=LOGICAL_CLOCK(MySQL8.0.26之前)

这个配置要求replica_preseve_commit_order=ON或者slave_preserve_commit_order=ON，这两个参数决定副本中(从库中)哪些并发可以并行的执行。

设置replica_parallel_workers=0或者slave_parallel_workers=0可以禁用并发执行，并且只有一个apllier线程没有协调线程。使用replica_parallel_workers=0或者slave_parallel_workers=0这种设置的话，replica_parallel_type(或者slave_parallel_type)和replica_preserve_commit_order(或者slave_preserve_commit_order)选项会被忽略，不会产生影响。从MySQL8.0.27开始，当主从复制中使用了GTID的时候并行复制被禁用了，那么从库实际上只有一个worker的并发线程，以便利用无需访问文件位置即可重试事务的方法。然而，这种行为对于用户来说没有任何变化。

replica_preserve_commit_order：

从MySQL 8.0.27开始，默认开启，确保事务在副本上执行和提交的顺序与它们在副本的中继日志中出现的顺序相同，正在执行的工作线程会等到所有先前的事务都已提交后再提交。当给定的线程正在等待其他工作线程提交它们的事务时，它将其状态报告为Waiting for preceding transaction to commit




replica_parallel_type:定义从库并行复制的策略或者模式，这个变量控制如何将复制时间分配给不通的woker线程以便并行执行。

作用：

决定并行方式: 根据设置的类型，从服务器处理并行复制的逻辑会有所不同。
优化复制策略: 不同的并行类型可能对特定的工作负载和复制场景更有效。
选项:

DATABASE: 按数据库分配事件给不同的worker。只有当事务涉及的修改操作限定在不同的数据库时，这些事务才能并行。
LOGICAL_CLOCK: 使用逻辑时钟来决定哪些事件可以安全地并行应用。这种方法可以提供跨多个数据库的更广泛的并行度。

replica_parallel_workers


定义： replica_parallel_workers（在某些版本中被称作slave_parallel_workers）指定了在从服务器上用于并行处理复制事件的工作线程数。

作用：

并行处理: 通过多个线程并行应用事件（比如事务），从而加速事务的复制过程。
性能提升: 当主服务器上多个事务彼此独立时，这种并行处理可以显著减少延迟，并提升从服务器处理复制数据的速度。
默认值与范围： 默认值通常为0，意味着不启用并行复制。可设置的值范围是0到MAX_WORKERS（依赖具体MySQL版本）之间的任何整数。

以上三个参数的解释引用自：https://blog.csdn.net/weixin_44265650/article/details/130079134

https://blog.csdn.net/jkzyx123/article/details/138184561

分离的XA事务

MySQL8.0.29及以后的版本支持分离的xa事务，分离的事务是指一旦准备好，就不需要连接到当前会话(即事务不必和会话进行绑定)。这是通过执行XA PREPARE命令时自动发生的。已准备的XA事务可以由另一个连接提交或回滚，而当前会话可以在不等待刚刚准备的事务完成的情况下启动另一个XA事务或本地事务。

当启用分离的XA事务支持（xa_detach_on_prepare = ON）时，连接到此服务器的任何连接都可以列出（使用XA RECOVER）、回滚或提交任何已准备的XA事务。此外，在分离的XA事务中，不能使用临时表(因为临时表是与特定会话关联的，而分离的XA事务不再与任何特定会话关联)。

可以通过将xa_detach_on_prepare设置为OFF来禁用对分离的XA事务的支持，但这并不推荐。特别是，如果此服务器是作为MySQL组复制的一个实例设置的，您应该将该变量保持为其默认值（ON）。

20.3.2 组复制的限制

以下对于组复制存在以下限制，注意：以下多主模式的限制对于单主模式在failover期间的event也可能适用，当新选出的主节点从旧主节点中刷新其应用队列时。

对于组复制功能，存在一些已知的限制。这些限制不仅适用于多主模式组，而且在单主模式集群的故障转移事件期间也可能适用。具体来说，当单主模式集群中的主节点发生故障，并且一个从节点被选举为新的主节点时，这个新的主节点需要处理一个称为“应用队列”（applier
queue）的队列，这个队列包含了从旧主节点那里还未被应用（即，还未被写入本地数据库）的变更。在这个过程中，可能会遇到一些与多主模式组相同的限制或问题。

Tip

  组复制是基于GTID进行的复制，所以也要参考一些复制期间关于gtid的限制。Section 19.1.3.7, “Restrictions on Replication with GTIDs”.

–upgrade=MINIMAL选项

在使用MINIMAL选项进行升级后的MySQL服务无法启动组复制(--upgrade=MINIMAL)，使用这个选项不会升级那些依赖于复制内部机制的系统表。

在 MySQL 的升级过程中，有时可能只想更新一些二进制文件或库，而不去更新或修改数据表的结构。–upgrade=MINIMAL
就是这样一个选项，它允许用户进行最小化的升级，只更新必要的二进制文件和库，而不去更新系统表或用户数据表。

然而，组复制（Group
Replication）依赖于某些系统表来维护复制的内部状态。如果这些系统表没有被正确更新或升级，那么组复制可能无法正常工作。因此，官方文档警告说，在使用
–upgrade=MINIMAL 选项进行升级后，不能立即启动组复制。

Gap Locks

在验证阶段中(certification process)，不会考虑 Gap Locks，因此在 InnoDB 的外部无法获取任何关于Gap 锁的信息

Note
除非你的应用程序或业务需求依赖于REPEATABLE READ(MySQL默认该隔离级别)，否则建议在组复制中使用READ
COMMITTED隔离级别。在READ COMMITTED隔离级别中，InnoDB基本上不会使用Gap
Locks，这将使得InnoDB自带的冲突探测能和组复制的冲突探测相互对齐从而保持一致。

table locks and named locks

验证期间不考虑表锁和命名(named locks)锁,命名锁可以参考(GET_LOCK())

binlog checksums

在MySQL8.0.20之前包括MySQL8.0.20，组复制不会使用checksum，并且不支持将checksum信息体现在binlog中，所以当你配置实例为组复制成员的时候必须设置binlog_checksum=NONE。从MySQL8.0.21开始，组复制支持checksums，所以组复制成员默认的binlog_checksum=CRC32。binlog_checksum也不必在所有的组成员节点中保持一致。
当校验和可用时，组复制不会在group_replication_applier通道上使用它们来验证传入的事件，因为这些事件是从多个源写入到中继日志的，并且在它们实际写入到原始服务器的二进制日志之前（此时生成校验和）。校验和用于验证group_replication_recovery通道以及组成员上的任何其他复制通道的事件的完整性。

在MySQL的组复制中，为了保持数据的一致性和完整性，校验和（checksums）是一个重要的机制。但是，在校验和的使用上，MySQL对不同的复制通道有不同的处理方式。

group_replication_applier通道：这是组复制中用于应用其他组成员所提交的事务的通道。由于这些事务（或称为“事件”）可能是从多个不同的组成员复制过来的，并且它们在被写入到原始服务器的二进制日志之前，就已经先被写入了中继日志（relay
log），所以在这个阶段，MySQL不会使用校验和来验证这些事件的完整性。
group_replication_recovery通道：这是用于恢复组成员之间数据一致性的通道。在这个通道上，MySQL会使用校验和来验证事件的完整性，以确保在恢复过程中数据不会被损坏或篡改。
其他复制通道：除了上述两个特定的组复制通道外，MySQL还会在其他任何复制通道上使用校验和来验证事件的完整性。

串行化隔离级别

串行化隔离级别不支持默认情况下组多主模式的组，在多主模式下设置串行化的事务隔离级别将拒绝提交事务。

并发的DDM和DML操作

不支持在多主模式下不同节点上同时执行数据定义语言DDL和数据操纵语言DML修改同一对象。在一个对象上执行DDL期间，在另一台server上执行同一个对象的DML有可以探测到数据冲突的风险。

是 DDL+DML 的并发，DDL+DDL
的并发也不允许。这是因为MySQL中没有DDL事务，不能保证DDL的原子性，当DDL和DML同时操作某一个对象，可能DDL修改后，DML将因为对象结构的改变而无法执行，继而回滚
该段引用自：https://www.cnblogs.com/zmc60/p/15180098.html

级联的外键约束

多主模式下的组复制(组成员配置为group_replication_single_primary_mod=OFF)不支持表中有多级级联的外键依赖，特别是定义了CASCADING外键约束的表。这是因为由多主模式组执行的级联操作可能导致未检测到的冲突，从而导致组成员间数据不一致。因此，官方建议在多主模式组中使用的服务器实例上设置group_replication_enforce_update_everywhere_checks=ON以避免未检测到的冲突。

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

多主模式死锁

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

复制过滤器

全局复制过滤器不能用于配置了组复制的 MySQL 服务器实例，因为对某些服务器上的事务进行过滤会使组无法就一致状态达成一致。但是，可以在不直接参与组复制的复制通道上使用特定于通道的复制过滤器，例如当组成员还作为组外部的源的副本(从库)时。这些过滤器不能用于group_replication_applier或group_replication_recovery通道。

加密连接

TLSv1.3 协议支持在 MySQL 8.0.16 及更高版本中可用，前提是 MySQL 是使用 OpenSSL 1.1.1 或更高版本编译的。在 MySQL 8.0.16 和 MySQL 8.0.17 中，如果服务器支持 TLSv1.3，则该协议在组通信引擎中不受支持，并且不能在组复制通道中使用。这意味着，尽管 MySQL 服务器本身可能支持 TLSv1.3，但在组复制通信中仍然需要使用早期版本的 TLS 协议（如 TLSv1.2）。
在 MySQL 8.0.18 中，TLSv1.3 可以用于组复制（Group Replication）的分布式恢复连接，但是系统变量 group_replication_recovery_tls_version 和 group_replication_recovery_tls_ciphersuites 不可用。因此，捐赠者服务器必须允许使用至少一个默认启用的 TLSv1.3 密码套件，这些密码套件列在“8.3.2 加密连接 TLS 协议和密码套件”一节中。从 MySQL 8.0.19 开始，您可以使用这些选项来配置客户端对任何密码套件的选择的支持，包括如果您愿意的话，仅非默认密码套件。

克隆操作

组复制启动并管理分布式恢复的克隆操作，但已设置支持克隆的组成员也可以参与用户手动启动的克隆操作。在 MySQL 8.0.20 之前的版本中，如果操作涉及运行组复制的组成员，则无法手动启动克隆操作。从 MySQL 8.0.20 开始，您可以这样做，前提是克隆操作不删除并替换接收方的数据。因此，启动克隆操作的语句（如果组复制正在运行）必须包含 DATA DIRECTORY 子句。请参阅“20.5.4.2.4 Cloning for Other Purposes”。

Limit on Group Size

单个复制组的成员最多为9个，如果要加入更多的节点，加入组的请求会被拒绝。这个限制已经通过测试和基准测试被确定为一个安全的边界，在该边界内，组在稳定的局域网中可以可靠地运行。

Limits on Transaction Size

如果独立事务消息内容太大，大到在5s的窗口内无法在组成员之间复制消息，那么组成员可能就被怀疑失联或者挂掉了(failed)。然后就会驱逐该成员，仅仅是因为成员在忙于处理事务而被驱逐。大事务也会由于内存分配问题导致系统变慢。为了避免这些问题可以使用以下缓解措施：

1.增加被驱逐检测额外的时间

如果是因为大型消息而导致不必要的驱逐，可以使用系统变量group_replication_member_expel_timeout在怀疑失败的成员被驱逐之前提供额外的时间。在初始的 5 秒检测期之后，允许多达一小时的额外时间，然后才将怀疑的成员从组中驱逐。从 MySQL 8.0.21 开始，默认情况下额外允许 5 秒。

2.对大消息进行分片

有可能的情况下， 在交Group Replication 处理之前，尽量限制事务的大小。例如，将与LOAD DATA一起使用的文件拆分为较小的块。

3.限制事务大小

使用group_replication_transaction_size_limit指定组可以接受的事务的最大大小。在MySQL8.0中，这个系统变量默认是150000000 字节,大概等于143MB。超过这个大小的事务将会被回滚，并且不会发送给组复制的Group Communication System(GCS)以分发给组。根据您需要组容忍的最大消息大小调整此变量的值，处理事务所需的时间与其大小成正比。

4.压缩消息

通过group_replication_compression_threshold系统变量指定应用压缩的消息大小阈值。这个系统变量默认大小为1000000字节(1MB)，所以比较大的消息会自动压缩。当 Group Replication 的 Group Communication System(GCS)接收到一个由group_replication_transaction_size_limit设置允许但超过group_replication_compression_threshold设置的消息时，将执行压缩。(未超过限制事务大小，但超过压缩阈值则进行压缩)。

5.消息分段

使用系统变量group_replication_communication_max_message_size来指定应用分段的消息大小阈值。该系统变量默认为 10485760 字节（10 MB），因此大消息会自动进行分段。如果压缩后的消息仍超过group_replication_communication_max_message_size限制，GCS 将在压缩后执行分段。为了使复制组使用分段，所有组成员必须使用 MySQL 8.0.16 或更高版本，并且组使用的 Group Replication 通信协议版本必须允许分段。更多信息，请参见第 20.7.5 节，“Message Fragmentation”。

最大事务的大小、消息压缩和消息分段都可以通过指定相关系统变量为零来停用。如果您已停用了所有这些保护措施，那么在复制组成员的应用程序线程可以处理的消息的上限大小是成员的replica_max_allowed_packet或slave_max_allowed_packet系统变量的值，这些变量的默认和最大值为 1073741824 字节（1 GB）。当接收成员尝试处理超过此限制的消息时，消息将失败。组成员可以发起并尝试传输到组的消息的上限大小为 4294967295 字节（约 4 GB）。这是接受由组复制（XCom，一种 Paxos 变体）的组通信引擎处理后的消息的数据包大小的硬限制，GCS 在处理消息后接收它们。当发起成员尝试广播超过此限制的消息时，消息将失败。