From MySQL 8.0.19, as well as securing asynchronous and
semi-synchronous replication, you may choose to use a
PRIVILEGE_CHECKS_USER
account to secure the
two replication applier threads used by Group Replication. The
group_replication_applier
thread on each
group member is used for applying the group's transactions, and
the group_replication_recovery
thread on each
group member is used for state transfer from the binary log as
part of distributed recovery when the member joins or rejoins
the group.
To secure one of these threads, stop Group Replication, then
issue the CHANGE REPLICATION SOURCE
TO
statement (from MySQL 8.0.23) or
CHANGE MASTER TO
statement
(before MySQL 8.0.23) with the
PRIVILEGE_CHECKS_USER
option, specifying
group_replication_applier
or
group_replication_recovery
as the channel
name. For example:
mysql> STOP GROUP_REPLICATION;
mysql> CHANGE MASTER TO PRIVILEGE_CHECKS_USER = 'gr_repl'@'%.example.com'
FOR CHANNEL 'group_replication_recovery';
mysql> FLUSH PRIVILEGES;
mysql> START GROUP_REPLICATION;
Or from MySQL 8.0.23:
mysql> STOP GROUP_REPLICATION;
mysql> CHANGE REPLICATION SOURCE TO PRIVILEGE_CHECKS_USER = 'gr_repl'@'%.example.com'
FOR CHANNEL 'group_replication_recovery';
mysql> FLUSH PRIVILEGES;
mysql> START GROUP_REPLICATION;
For Group Replication channels, the
REQUIRE_ROW_FORMAT
setting is automatically
enabled when the channel is created, and cannot be disabled, so
you do not need to specify this.
In MySQL 8.0.19, ensure that you do not issue the
CHANGE REPLICATION SOURCE TO
|
CHANGE MASTER TO
statement with
the PRIVILEGE_CHECKS_USER
option while
Group Replication is running. This action causes the relay log
files for the channel to be purged, which might cause the loss
of transactions that have been received and queued in the
relay log, but not yet applied.
Group Replication requires every table that is to be replicated
by the group to have a defined primary key, or primary key
equivalent where the equivalent is a non-null unique key. Rather
than using the checks carried out by the
sql_require_primary_key
system
variable, Group Replication has its own built-in set of checks
for primary keys or primary key equivalents. You may set the
REQUIRE_TABLE_PRIMARY_KEY_CHECK
option of the
CHANGE REPLICATION SOURCE TO
|
CHANGE MASTER TO
statement to
ON
for a Group Replication channel. However,
be aware that you might find some transactions that are
permitted under Group Replication's built-in checks are not
permitted under the checks carried out when you set
sql_require_primary_key = ON
or
REQUIRE_TABLE_PRIMARY_KEY_CHECK = ON
. For
this reason, new and upgraded Group Replication channels from
MySQL 8.0.20 (when the option was introduced) have
REQUIRE_TABLE_PRIMARY_KEY_CHECK
set to the
default of STREAM
, rather than to
ON
.
If a remote cloning operation is used for distributed recovery
in Group Replication (see
Section 20.5.4.2, “Cloning for Distributed Recovery”), from MySQL 8.0.19,
the PRIVILEGE_CHECKS_USER
account and related
settings from the donor are cloned to the joining member. If the
joining member is set to start Group Replication on boot, it
automatically uses the account for privilege checks on the
appropriate replication channels.
In MySQL 8.0.18, due to a number of limitations, it is
recommended that you do not use a
PRIVILEGE_CHECKS_USER
account with Group
Replication channels.