20.4.1 GTIDs和组复制

组复制使用GTID精确跟踪每个服务器上的实例已提交的事务。所有组成员都需要设置gtid_mode=on和enforce_gtid_consistency=on。从客户端接收的事务由接收它们的组成员分配一个GTID。任何通过异步复制通道从组外源服务器接收的复制事务，在到达组成员时都保留其原有的GTID。

GTID的分配：当客户端向组中的某个成员发送事务时，该成员会为该事务分配一个GTID。这个GTID是全局唯一的，并且可以被组中的其他成员识别和追踪。
保留外部源服务器的GTID：如果组中的成员从组外的源服务器通过异步复制通道接收了事务，这些事务将保留它们原有的GTID。这意味着，即使这些事务是在组外部生成的，但一旦它们进入组，它们就可以被组中的所有成员识别、追踪和复制。

分配给来自客户端的入站事务的GTID使用group_replication_group_name系统变量指定的组名作为标识符的UUID部分，而不是接收该事务的单个组成员的服务器UUID。因此，所有直接由组接收的事务都可以被识别，并且以GTID集合的形式组合在一起，而无论最初是由哪个成员接收的。每个组成员都会为其使用预留一段连续的GTID块，当这些GTID被消耗时，它会预留更多。group_replication_gtid_assignment_block_size系统变量设置了这些块的大小，默认为每个块1百万个GTID。

GTID的UUID部分：在MySQL的组复制中，GTID的UUID部分不是基于接收事务的单个服务器的UUID，而是基于整个组的UUID，这个组的UUID是通过group_replication_group_name系统变量指定的。这样，无论事务是由哪个组成员接收的，它都会被分配一个与整个组相关的GTID。
GTID的分组和识别：由于所有组接收的事务都使用相同的组UUID作为GTID的一部分，因此可以很容易地将它们组合在一起，形成一个GTID集合。这样，即使事务是在不同的组成员上接收的，也可以轻松地将它们识别为属于同一个组的事务。
GTID的分配和预留：为了高效地分配GTID，每个组成员都会为其使用预留一段连续的GTID块。当这些GTID被消耗时，该成员会再次预留更多的GTID块。group_replication_gtid_assignment_block_size系统变量允许你配置每个GTID块的大小，默认是每个块1百万个GTID。这种设计可以提高GTID分配的效率，并减少成员之间不必要的GTID同步操作。

视图更改事件(view_change_log_event)，当有成员加入进来之后由组本身自动生成，这些事件记录到binlog时也会分配GTIDs。默认情况下，
视图变更事件（View_change_log_event），当新成员加入组时由组本身生成，这些事件在记录到二进制日志时会分配全局事务标识符（GTIDs）。默认情况下，这些事件的GTIDs也使用由group_replication_group_name系统变量指定的组名作为标识符的UUID部分。从MySQL 8.0.26开始，可以通过设置组复制系统变量group_replication_view_change_uuid，在视图变更事件的GTIDs中使用一个替代的UUID，以便轻松地将它们与组从客户端接收的事务区分开来。如果您的设置允许组之间进行故障转移，并且您需要识别和丢弃特定于备份组的事务，那么这将非常有用。替代UUID必须与成员服务器的UUID不同，也必须与使用CHANGE REPLICATION SOURCE TO语句的ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS选项应用于匿名事务的GTIDs中的任何UUID不同。

下图引用自链接：https://zhuanlan.zhihu.com/p/40627399

此处也推荐阅读大佬(老叶茶馆)的文章，解释的很细致：https://cloud.tencent.com/developer/article/1697518

从MySQL8.0.27开始，设置 GTID_ONLY=1、REQUIRE_ROW_FORMAT = 1 和 SOURCE_AUTO_POSITION = 1 适用于 Group Replication 通道 group_replication_applier 和 group_replication_recovery。这些设置在创建 Group Replication 通道时自动设置，或者当复制组中的成员服务器升级到 8.0.27 或更高版本时自动设置。通常使用 CHANGE REPLICATION SOURCE TO 语句设置这些选项，但请注意，您无法为 Group Replication 通道禁用它们。设置了这些选项后，组成员不会在这些通道的复制元数据存储库中持久保存文件名和文件位置。在必要时，GTID 自动定位和 GTID 自动跳过用于定位正确的接收器和应用程序位置。

额外事务

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

如果在 Group Replication 停止时在实例上执行管理事务，则可能会存在额外的事务。为了避免以这种方式引入新事务，请在发出管理语句之前始终将 sql_log_bin 系统变量的值设置为 OFF，然后在之后设置回 ON

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

将此系统变量设置为 OFF 意味着从那一点开始发生的事务不会写入二进制日志，并且不会分配 GTID。

如果加入成员存在额外的事务，请检查受影响服务器的二进制日志，查看额外事务的实际内容。将加入成员的数据和 GTID 集与当前组中的成员进行协调的最安全方法是使用 MySQL 的克隆功能，将内容从组中的一个服务器传输到受影响的服务器。有关如何执行此操作的说明，请参见 Section 7.6.7.3, “克隆远程数据”。如果需要该事务，请在成员成功重新加入后重新运行它。