当您确定不存在用户错误,而复制仍然无法正常工作或不稳定时,就该向我们发送错误报告了。我们需要从您那里获取尽可能多的信息,以便追踪错误。请花一些时间和精力准备一份好的错误报告。
如果您有一个可重复的测试用例可以演示错误,请使用 第 1.6 节“如何报告错误或问题” 中给出的说明将其输入到我们的错误数据库中。如果您遇到了 “幽灵” 问题(您无法随意复制的问题),请使用以下步骤
验证不存在用户错误。例如,如果您在复制线程之外更新副本,数据就会不同步,您可能会在更新时遇到唯一键冲突。在这种情况下,复制线程会停止并等待您手动清理表,以便将其同步。 这不是复制问题。这是外部干扰导致复制失败的问题。
确保副本在启用二进制日志记录(
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.6 节“如何报告错误或问题” 中的说明,将问题及其尽可能多的信息输入到我们的错误数据库中。