组复制使用 GTIDs(全局事务标识符)来跟踪每个服务器实例上提交的确切事务。所有组成员都需要设置 gtid_mode=ON
和 enforce_gtid_consistency=ON
。来自客户端的入站事务将被分配 GTID 由接收事务的组成员分配。来自源服务器的异步复制通道上的复制事务保留其原始 GTID。
来自客户端的入站事务的 GTID 使用 group_replication_group_name
系统变量指定的组名作为标识符的 UUID 部分,而不是接收事务的个体组成员的服务器 UUID。因此,所有直接由组接收的事务都可以被识别和分组在 GTID 集合中,不管它们最初是由哪个成员接收的。每个组成员都保留了一块连续的 GTID 块供其使用,当这些块被消耗时,它将保留更多。group_replication_gtid_assignment_block_size
系统变量设置了块的大小,默认为每块 1 百万个 GTID。
视图更改事件 (View_change_log_event
) 由组自身生成,当新成员加入时,这些事件在二进制日志中被记录。默认情况下,这些事件的 GTID 也使用 group_replication_group_name
系统变量指定的组名作为标识符的 UUID 部分。你可以设置组复制系统变量 group_replication_view_change_uuid
以使用备用 UUID 在视图更改事件的 GTID 中,以便于区分来自客户端的事务。如果您的设置允许组之间的故障转移,您需要识别和丢弃特定于备份组的事务。备用 UUID 必须不同于成员的服务器 UUID,也不同于使用 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
选项的匿名事务的 GTID。
GTID_ONLY=1
、REQUIRE_ROW_FORMAT = 1
和 SOURCE_AUTO_POSITION = 1
将应用于组复制通道 group_replication_applier
和 group_replication_recovery
。这些设置将自动应用于组复制通道的创建或成员服务器升级(到 MySQL 8.0.27 或更高版本)时。这些选项通常使用 CHANGE REPLICATION SOURCE TO
语句设置,但请注意,您不能禁用这些选项 для组复制通道。使用这些选项设置后,组成员不会在复制元数据存储库中持久化文件名和文件位置。
如果加入成员的 GTID 集合中包含不在现有成员中的事务,它将无法完成分布式恢复过程,无法加入组。如果远程克隆操作被执行,这些事务将被删除和丢失,因为加入成员的数据目录将被擦除。如果从捐赠者的二进制日志中传输状态,这些事务可能与组的事务冲突。
如果在组复制停止时在实例上执行管理事务,可能会在成员上引入额外的事务。为了避免这种情况,始终在执行管理语句前将 sql_log_bin
系统变量设置为 OFF
,然后将其设置回 ON
:
SET SQL_LOG_BIN=0;
<administrator action>
SET SQL_LOG_BIN=1;
将该系统变量设置为 OFF
意味着从那时起直到您将其设置回 ON
的事务将不会被写入二进制日志,也不会被分配 GTID。
如果加入成员上存在额外的事务,请检查受影响的服务器的二进制日志,以查看该额外事务实际包含的内容。将加入成员的数据和 GTID 集与组中当前成员的数据和 GTID 集保持一致的最安全方法是使用 MySQL 的克隆功能将内容从组中的服务器传输到受影响的服务器。有关执行此操作的说明,请参阅 第 7.6.7.3 节,“远程数据克隆”。如果需要事务,请在成员成功重新加入后重新运行它。