MySQL 9.4 Release Notes
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.
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 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, 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.
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.
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;
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.
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.6.3, “Cloning Remote Data”. If the transaction is required, rerun it after the member has successfully rejoined.