确认没有用户错误。例如，如果您在复制线程之外更新副本，数据会失去同步，并且在更新时可能出现唯一键冲突。在这种情况下，复制线程会停止并等待您手动清理表以使其同步。这不是复制问题。这是外部干扰导致复制失败的问题。Verify that no user error is involved. For example, if you update the replica outside of the replication threads, the data goes out of synchrony, and you can have unique key violations on updates. In this case, the replication thread stops and waits for you to clean up the tables manually to bring them into synchrony. This is not a replication problem. It is a problem of outside interference causing replication to fail.

确保副本在启用二进制日志记录的情况下运行（log_bin 系统变量），并启用 --log-replica-updates 选项，这会导致副本将从源接收到的更新记录到自己的二进制日志中。这些设置是默认设置。Ensure that the replica is running with binary logging enabled (the log_bin system variable), and with the --log-replica-updates option enabled, which causes the replica to log the updates that it receives from the source into its own binary logs. These settings are the defaults.

在重置复制状态之前保存所有证据。如果我们没有信息或只有零散信息，我们就很难甚至无法追踪问题。你应该收集的证据是：Save all evidence before resetting the replication state. If we have no information or only sketchy information, it becomes difficult or impossible for us to track down the problem. The evidence you should collect is:

使用 mysqlbinlog 来检查二进制日志。以下内容应有助于找到问题语句。 log_file 和 log_pos 是来自 SHOW REPLICA STATUS 的 Master_Log_File 和 Read_Master_Log_Pos 值。Use mysqlbinlog to examine the binary logs. The following should be helpful to find the problem statement. log_file and log_pos are the Master_Log_File and Read_Master_Log_Pos values from SHOW REPLICA STATUS.

$> mysqlbinlog --start-position=log_pos log_file | head