MySQL 8.3 Release Notes
如果您按照说明进行了设置，但复制设置不起作用，第一件事就是 检查错误日志中的消息。许多用户花费了太多时间，因为他们没有及时地执行这项操作。
如果您无法从错误日志中确定问题所在，尝试以下技术：
-
通过发出
SHOW BINARY LOG STATUS语句来验证源是否启用了二进制日志记录。二进制日志记录默认启用。如果二进制日志记录启用，Position将不是零。如果二进制日志记录未启用，请验证您是否在源上使用了禁用二进制日志记录的设置，例如--skip-log-bin选项。 -
验证
server_id系统变量是否在源和副本上启动，并且每个服务器上的 ID 值是否唯一。 -
验证副本是否正在运行。使用
SHOW REPLICA STATUS来检查Replica_IO_Running和Replica_SQL_Running值是否都是Yes。如果不是，请验证副本服务器启动时使用的选项。例如，--skip-replica-start防止复制线程启动，直到您发出START REPLICA语句。 -
如果副本正在运行，请检查它是否与源建立了连接。使用
SHOW PROCESSLIST，找到 I/O（receiver）和 SQL（applier）线程，并检查它们的State列以查看它们显示的内容。见 第 19.2.3 节，“复制线程”。如果接收器线程状态显示Connecting to master，请检查以下内容：-
验证源上的复制用户权限。
-
检查源的主机名是否正确，并且您是否使用正确的端口连接到源。用于复制的端口与用于客户端网络通信的端口相同（默认为
3306）。对于主机名，请确保名称解析到正确的 IP 地址。 -
检查配置文件，以查看是否在源或副本上启用了
skip_networking系统变量以禁用网络。如果是，请注释该设置或删除它。 -
如果源有防火墙或 IP 筛选配置，请确保 MySQL 使用的网络端口未被筛选。
-
使用
ping或traceroute/tracert来检查是否可以到达源主机。
-
-
如果副本之前曾经运行过，但现在停止了，原因通常是源上的某个语句在副本上失败了。这永远不应该发生，如果您已经正确地拍摄了源的快照，并且从不在副本上以外的复制线程之外修改数据。如果副本意外停止了，这可能是一个 bug 或您遇到了已知的复制限制，见 第 19.5.1 节，“复制功能和问题”。如果这是一个 bug，请见 第 19.5.5 节，“如何报告复制 bug 或问题”，以获取报告指令。
-
如果源上的某个语句在副本上失败了，尝试以下过程，如果不可能对副本的数据库进行完整的重新同步，例如删除副本的数据库并从源复制新的快照：
-
确定副本上的受影响表是否与源上的表不同。尝试了解这是如何发生的。然后，使副本的表与源的表相同，并运行
START REPLICA。 -
如果前一步骤不起作用或不适用，尝试了解是否可以手动更新（如果需要），然后忽略源上的下一语句。
-
如果您决定副本可以跳过源上的下一语句，发出以下语句：
mysql> SET GLOBAL sql_replica_skip_counter = N; mysql> START REPLICA;如果下一条来自源的语句不使用
N，则其值应为 1。AUTO_INCREMENT或LAST_INSERT_ID()。否则，值应为 2。使用 2 的原因是，使用AUTO_INCREMENT或LAST_INSERT_ID()的语句在源的二进制日志中占用两个事件。 -
如果您确定副本从源开始完全同步，并且没有人在复制线程外更新了相关表，则差异可能是 bug 的结果。如果您正在运行最新版本的 MySQL，请报告问题。如果您正在运行旧版本，请尝试升级到最新的生产版本，以确定问题是否仍然存在。
-