# 18.4.1 GTID 和组复制

组复制使用 GTID(全局事务标识符)来准确跟踪每个服务器实例上已提交的事务。设置gtid_mode=ONenforce_gtid_consistency=ON所有组成员都需要。来自客户端的传入事务由接收它们的组成员分配一个 GTID。组成员在异步复制通道上从组外的源服务器接收到的任何复制事务都会保留它们在到达组成员时所拥有的 GTID。

分配给来自客户端的传入事务的 GTID 使用由group_replication_group_name系统变量作为标识符的 UUID 部分,而不是接收事务的单个组成员的服务器 UUID。因此,该组直接接收到的所有事务都可以被识别并在 GTID 集中分组在一起,而最初接收它们的成员无关紧要。每个组成员都有一个连续的 GTID 块供其使用,当这些 GTID 被消耗时,它会保留更多。这group_replication_gtid_assignment_block_size系统变量设置块的大小,每个块默认为 100 万个 GTID。

查看更改事件 (View_change_log_event),当新成员加入时由组本身生成,当它们记录在二进制日志中时会被赋予 GTID。默认情况下,这些事件的 GTID 也使用由group_replication_group_name系统变量作为标识符的 UUID 部分。从 MySQL 8.0.26 开始,您可以设置 Group Replication 系统变量group_replication_view_change_uuid在 GTID 中使用替代 UUID 来处理视图更改事件,以便将它们与组从客户端接收的事务区分开来。如果您的设置允许组之间的故障转移,并且您需要识别和丢弃特定于备份组的事务,这将很有用。备用 UUID 必须不同于成员的服务器 UUID。它还必须不同于应用到匿名事务的 GTID 中的任何 UUID,使用ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS的选项将复制源更改为陈述。

从 MySQL 8.0.27 开始,设置GTID_ONLY=1,REQUIRE_ROW_FORMAT = 1, 和SOURCE_AUTO_POSITION = 1应用于组复制通道group_replication_appliergroup_replication_recovery.创建组复制通道时,或复制组中的成员服务器升级到 8.0.27 或更高版本时,这些设置会自动在组复制通道上进行。这些选项通常使用将复制源更改为声明,但请注意,您不能为组复制通道禁用它们。设置这些选项后,组成员不会在这些通道的复制元数据存储库中保留文件名和文件位置。GTID 自动定位和 GTID 自动跳过用于在必要时定位正确的接收器和应用程序位置。

# 额外交易

如果加入的成员在其 GTID 集中的事务在组的现有成员上不存在,则不允许完成分布式恢复过程,并且不能加入组。如果执行了远程克隆操作,这些事务将被删除并丢失,因为加入成员上的数据目录被删除。如果从捐赠者的二进制日志进行状态转移,这些事务可能会与组的事务发生冲突。

如果在停止组复制时在实例上执行管理事务,则成员上可能存在额外事务。为避免以这种方式引入新交易,请始终设置sql_log_bin系统变量为离开在发布行政声明之前,然后返回然后:

SET SQL_LOG_BIN=0;
<administrator action>
SET SQL_LOG_BIN=1;

将此系统变量设置为离开表示从该点发生的事务直到您将其设置回不会写入二进制日志,也没有分配给它们的 GTID。

如果加入成员上存在额外事务,请检查受影响服务器的二进制日志以查看额外事务实际包含的内容。将加入成员的数据和 GTID 集与当前组中的成员进行协调的最安全方法是使用 MySQL 的克隆功能将内容从组中的服务器传输到受影响的服务器。有关执行此操作的说明,请参阅第 5.6.7.3 节,“克隆远程数据”.如果需要交易,请在会员成功重新加入后重新运行。