Identify the replicated event that caused the error and verify whether or not the event is expected and from a trusted source. You can usemysqlbinlogto retrieve and display the events that were logged around the time of the error. For instructions to do this, seeSection 7.5, “Point-in-Time (Incremental) Recovery”.

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.

If thePRIVILEGE_CHECKS_USERaccount 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.

如果事务需要执行哈ve verified that it is trusted, but thePRIVILEGE_CHECKS_USERaccount should not have this privilege normally, you can grant the required privilege to thePRIVILEGE_CHECKS_USERaccount 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.

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 issueSTART REPLICA | SLAVEto restart replication on the channel. To avoid the situation in future, you could issue such administrative statements withSET sql_log_bin = 0before them andSET sql_log_bin = 1after them, so that they are not logged on the source.

If the transaction is a DDL or DML statement that should not have taken place on either the source or the replica, skip the transaction on the server or servers where it stopped replication, undo the transaction manually on the server where it originally took place, then issueSTART REPLICA | SLAVEto restart replication.