MySQL 8.3 Release Notes
当您确定没有用户错误参与，并且复制仍然不工作或不稳定时，就是时候向我们报告错误了。我们需要从您那里获得尽可能多的信息，以便追踪错误。请花些时间和精力准备一个好的错误报告。
如果您有一个可以重复的测试用例来演示错误，请按照第 1.5 节，“如何报告错误或问题”中的说明将其输入我们的错误数据库。如果您有一个“幽灵”问题（一个您无法重复的错误），请使用以下过程：
-
验证没有用户错误参与。例如，如果您在复制线程外更新副本，数据就会不同步，并且您可能会在更新时遇到唯一键违规。在这种情况下，复制线程将停止并等待您手动清理表以使其同步。这不是复制问题。这是一个外部干扰导致复制失败的问题。
-
确保副本以启用二进制日志记录（
log_bin系统变量）和启用--log-replica-updates选项，后者使副本将从源接收的更新记录到其自己的二进制日志中。这些设置是默认的。 -
在重置复制状态之前，保存所有证据。如果我们没有信息或只有模糊的信息，那么追踪问题将变得困难或不可能。您应该收集的证据是：
-
所有源的二进制日志文件
-
所有副本的二进制日志文件
-
在发现问题时源的
SHOW BINARY LOG STATUS输出 -
在发现问题时副本的
SHOW REPLICA STATUS输出 -
源和副本的错误日志
-
-
使用mysqlbinlog检查二进制日志。以下信息将有助于找到问题语句。
log_file和log_pos是SHOW REPLICA STATUS中的Master_Log_File和Read_Master_Log_Pos值。$> mysqlbinlog --start-position=log_pos log_file | head
在收集了问题的证据后，首先尝试将其隔离为一个单独的测试用例。然后，按照第 1.5 节，“如何报告错误或问题”中的说明将问题输入我们的错误数据库。