Replication Privilege Checks 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 18.5.3.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. 17.3.3.3 Recovering From Failed Replication Privilege Checks If a privilege check against the  PRIVILEGE_CHECKS_USER  account fails, the transaction is not executed and replication stops for the channel. Details of the error and the last applied transaction are recorded in the Performance Schema  replication_applier_status_by_worker  table. Follow this procedure to recover from the error: 1. Identify the replicated event that caused the error and verify whether or not the event is expected and from a trusted source. You can use  mysqlbinlog  to retrieve and display the events that were logged around the time of the error. For instructions to do this, see Section 7.5, “Point-in-Time (Incremental) Recovery” . 2. If the replicated event is not expected or is not from a known and trusted source, investigate the cause. If you can identify why the event took place and there are no security considerations, proceed to fix the error as described below. 3. If the  PRIVILEGE_CHECKS_USER  account should have been permitted to execute the transaction, but has been misconfigured, grant the missing privileges to the account and restart replication for the channel. 4. If the transaction needs to be executed and you have verified that it is trusted, but the PRIVILEGE_CHECKS_USER  account should not have this privilege normally, you can grant the required privilege to the  PRIVILEGE_CHECKS_USER  account temporarily. After the replicated event has been applied, remove the privilege from the account, and take any necessary steps to ensure the event does not recur if it is avoidable. 5. If the transaction is an administrative action that should only have taken place on the source and not on the replica, or should only have taken place on a single replication group member, skip the transaction on the server or servers where it stopped replication, then issue  START REPLICA | SLAVE  to restart replication on the channel. To avoid the situation in future, you could issue such administrative 3627