MySQL 8.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列以查看显示的内容。请参见第 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。使用 2 的值用于使用AUTO_INCREMENT或LAST_INSERT_ID()的语句的原因是它们在源的二进制日志中占用两个事件。如果您确定副本最初与源完全同步，并且没有人更新了复制线程以外的涉及的表，那么推测不一致是错误造成的。如果您运行的是最新版本的 MySQL，请报告问题。如果您运行的是旧版本，请尝试升级到最新的生产版本，以确定问题是否仍然存在。