MySQL 8.4 Release Notes
组复制使用 GTID（全局事务标识符）来精确跟踪每个服务器实例上已提交的事务。所有组成员都需要设置 gtid_mode=ON 和 enforce_gtid_consistency=ON。客户端发起的事务由接收它们的组成员分配 GTID。通过异步复制通道从组外源服务器接收到的任何复制事务，在到达组成员时会保留其原有的 GTID。Group Replication uses GTIDs (global transaction identifiers) to
track exactly which transactions have been committed on every
server instance. The settings
gtid_mode=ON and
enforce_gtid_consistency=ON are
required on all group members. Incoming transactions from clients
are assigned a GTID by the group member that receives them. Any
replicated transactions that are received by group members on
asynchronous replication channels from source servers outside the
group retain the GTIDs that they have when they arrive on the
group member.
分配给来自客户端的入站事务的 GTID 使用 group_replication_group_name 系统变量指定的组名作为标识符的 UUID 部分，而不是接收该事务的单个组成员的服务器 UUID。因此，所有直接由组接收的事务都可以被识别，并在 GTID 集中归为一组，而不论最初由哪个成员接收。每个组成员都有一块为其使用预留的连续 GTID，当这些使用完时会预留更多。group_replication_gtid_assignment_block_size 系统变量设置这些块的大小，每块默认包含 100 万个 GTID。The GTIDs that are assigned to incoming transactions from clients
use the group name specified by the
group_replication_group_name
system variable as the UUID part of the identifier, rather than
the server UUID of the individual group member that received the
transaction. All the transactions received directly by the group
can therefore be identified and are grouped together in GTID sets,
and it does not matter which member originally received them. Each
group member has a block of consecutive GTIDs reserved for its
use, and when these are consumed it reserves more. The
group_replication_gtid_assignment_block_size
system variable sets the size of the blocks, with a default of 1
million GTIDs in each block.
视图更改事件（View_change_log_event）是由组在有新成员加入时生成的事件，当它们记录在二进制日志中时，会被赋予 GTID。默认情况下，这些事件的 GTID 也使用由 group_replication_group_name 系统变量指定的组名作为标识符的 UUID 部分。你可以设置组复制系统变量 group_replication_view_change_uuid，在视图更改事件的 GTID 中使用另一个 UUID，以便区分它们与组从客户端接收到的事务。这在你的设置允许组间故障转移时尤其有用，因为你可能需要识别并丢弃特定于备份组的事务。备用 UUID 必须不同于成员的服务器 UUID，也必须不同于在使用 CHANGE REPLICATION SOURCE TO 语句的 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 选项应用于匿名事务的 GTID 中的任何 UUID。View change events (View_change_log_event),
which are generated by the group itself when a new member joins,
are given GTIDs when they are recorded in the binary log. By
default, the GTIDs for these events also use the group name
specified by the
group_replication_group_name
system variable as the UUID part of the identifier. You can set
the Group Replication system variable
group_replication_view_change_uuid
to use an alternative UUID in the GTIDs for view change events, so
that they are easy to distinguish from transactions received by
the group from clients. This can be useful if your setup allows
for failover between groups, and you need to identify and discard
transactions that were specific to the backup group. The
alternative UUID must be different from the server UUIDs of the
members. It must also be different from any UUIDs in the GTIDs
applied to anonymous transactions using the
ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS option
of the CHANGE REPLICATION SOURCE TO statement.
GTID_ONLY=1、REQUIRE_ROW_FORMAT =
1 和 SOURCE_AUTO_POSITION = 1 被应用于组复制通道 group_replication_applier 和 group_replication_recovery。当创建组复制通道或复制组中的成员服务器升级时，这些设置会自动应用于组复制通道。这些选项通常使用 CHANGE REPLICATION SOURCE TO 语句进行设置，但请注意，不能为组复制通道禁用它们。设置这些选项后，组成员不会在这些通道的复制元数据存储库中保留文件名和文件位置。在必要时，会使用 GTID 自动定位和 GTID 自动跳过来确定正确的接收者和应用者位置。GTID_ONLY=1, REQUIRE_ROW_FORMAT =
1, and SOURCE_AUTO_POSITION = 1 are
applied for the Group Replication channels
group_replication_applier and
group_replication_recovery. The settings are
made automatically on the Group Replication channels when they are
created, or when a member server in a replication group is
upgraded. These options are normally set using a
CHANGE REPLICATION SOURCE TO
statement, but note that you cannot disable them for a Group
Replication channel. With these options set, the group member does
not persist file names and file positions in the replication
metadata repositories for these channels. GTID auto-positioning
and GTID auto-skip are used to locate the correct receiver and
applier positions when necessary.
如果加入的成员在其 GTID 集中有一些事务在组中现有成员上不存在，则不允许完成分布式恢复过程，也不能加入该组。如果执行了远程克隆操作，这些事务将被删除并丢失，因为加入成员上的数据目录会被清除。如果从捐赠者的二进制日志执行了状态传输，这些事务可能会与组的事务发生冲突。If a joining member has transactions in its GTID set that are not present on the existing members of the group, it is not allowed to complete the distributed recovery process, and cannot join the group. If a remote cloning operation was carried out, these transactions would be deleted and lost, because the data directory on the joining member is erased. If state transfer from a donor's binary log was carried out, these transactions could conflict with the group's transactions.
如果在 Group Replication 停止时对实例执行了管理事务，成员上可能会出现额外的事务。为了避免通过这种方式引入新的事务，在发出管理语句之前，应始终将 sql_log_bin 系统变量的值设置为 OFF，并在之后再设置回 ON：Extra transactions might be present on a member if an
administrative transaction is carried out on the instance while
Group Replication is stopped. To avoid introducing new
transactions in that way, always set the value of the
sql_log_bin system variable to
OFF before issuing administrative statements,
and back to ON afterwards:
SET SQL_LOG_BIN=0; <administrator action> SET SQL_LOG_BIN=1;
将此系统变量设置为 OFF 意味着从该点开始到您将其设置回 ON 之间发生的事务不会写入二进制日志，也不会为其分配 GTID。Setting this system variable to OFF means
that the transactions that occur from that point until you set
it back to ON are not written to the binary
log and do not have GTIDs assigned to them.
如果在加入的成员上存在额外事务，请检查受影响服务器的二进制日志，以查看该额外事务的实际内容。将加入成员的数据和 GTID 集与当前组中的成员对齐的最安全方法是使用 MySQL 的克隆功能，将组中某台服务器的内容传输到受影响的服务器。有关操作说明，请参阅 第 7.6.7.3 节，“克隆远程数据”。如果事务是必需的，在成员成功重新加入后重新执行该事务。If an extra transaction is present on a joining member, check the binary log for the affected server to see what the extra transaction actually contains. The safest method to reconcile the joining member’s data and GTID set with the members currently in the group is to use MySQL's cloning functionality to transfer the content from a server in the group to the affected server. For instructions to do this, see Section 7.6.7.3, “Cloning Remote Data”. If the transaction is required, rerun it after the member has successfully rejoined.