MySQL 9.0 发行说明
如果您已按照说明操作，但复制设置无法正常工作，第一步是检查错误日志是否有消息。许多用户因为没有在遇到问题后立即这样做而浪费了时间。
如果您无法从错误日志中判断问题所在，请尝试以下技术
通过发出
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列以查看它们显示的内容。请参阅 第 19.2.3 节，“复制线程”。如果接收器线程状态显示Connecting to master，请检查以下内容验证源上的复制用户的权限。
检查源的主机名是否正确，以及您是否使用正确的端口连接到源。用于复制的端口与用于客户端网络通信的端口相同（默认值为
3306）。对于主机名，请确保该名称解析为正确的 IP 地址。检查配置文件以查看源或副本上是否启用了
skip_networking系统变量来禁用网络。如果是，请注释掉该设置或将其删除。如果源具有防火墙或 IP 过滤配置，请确保未过滤掉用于 MySQL 的网络端口。
使用
ping或traceroute/tracert检查您是否可以到达源，以到达主机。
如果副本之前运行但已停止，通常是因为源上成功执行的某些语句在副本上失败了。如果您已对源进行了适当的快照，并且从未在复制线程之外修改副本上的数据，则这种情况永远不会发生。如果副本意外停止，则表示存在错误或您遇到了第 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。对于使用AUTO_INCREMENT或LAST_INSERT_ID()的语句，使用 2 作为值的原因是它们在源的二进制日志中占用了两个事件。如果您确定副本最初与源完全同步，并且没有人通过复制线程以外的方式更新了涉及的表，那么差异很可能是由于错误造成的。如果您运行的是最新版本的 MySQL，请报告此问题。如果您运行的是旧版本，请尝试升级到最新的生产版本，以确定问题是否仍然存在。