MySQL 8.4 Release Notes
19.5.4 复制故障排除
如果您已经按照指令操作，但复制设置仍然不工作，那么首先需要检查错误日志中的消息。许多用户曾经因为没有及时检查错误日志而浪费了时间。
如果您不能从错误日志中确定问题的原因，尝试以下技术：
-
验证源服务器是否启用了二进制日志记录，方法是执行
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（接收器）和SQL（应用程序）线程，然后检查它们的State列，以查看它们显示的状态。见Section 19.2.3, “Replication Threads”。如果接收器线程状态显示为Connecting to master，请检查以下内容：-
验证复制用户在源服务器上的权限。
-
检查源服务器的主机名是否正确，并使用正确的端口连接到源服务器。用于复制的端口与用于客户端网络通信的端口相同（默认为
3306）。对于主机名，确保名称解析到正确的IP地址。 -
检查配置文件，以查看是否启用了
skip_networking系统变量。如果是，请注释或删除该设置。 -
如果源服务器有防火墙或IP过滤配置，确保MySQL使用的网络端口没有被过滤。
-
检查您是否可以访问源服务器，使用
ping或traceroute/tracert命令来访问主机。
-
-
如果复制服务器曾经运行过，但现在已经停止了，那么通常的原因是源服务器上的某个语句在复制服务器上失败了。这应该从不发生，如果您已经正确地拍摄了源服务器的快照，并且在复制服务器上没有修改数据，除了 replication 线程之外。如果复制服务器意外停止，那么这可能是一个错误或您遇到了已知的复制限制，详见第19.5.1节，“复制特性和问题”。如果这是一个错误，请查看第19.5.5节，“报告复制错误或问题的方法”，了解如何报告它。
-
如果源服务器上的语句在复制服务器上失败，尝试以下步骤，如果无法执行完整数据库重新同步，删除复制服务器的数据库，并从源服务器上复制一个新的快照：
-
确定复制服务器上的受影响表是否与源服务器上的表不同。尝试理解这是如何发生的。然后，使复制服务器的表与源服务器的表相同，并执行
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()的语句的原因是它们在源服务器的二进制日志中占用两个事件。 -
如果您确定复制服务器在开始时与源服务器同步，并且没有人在非 replication 线程中更新了相关表，那么明显的不一致是错误的结果。如果您正在运行最新版本的 MySQL，请报告问题。如果您正在运行较旧的版本，请升级到最新的生产版本，以确定问题是否仍然存在。
-