19.3.3.2 Privilege Checks For Group Replication Channels

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.

Important

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.