如果您已按照说明进行操作，但您的复制设置不起作用，那么首先要做的是检查错误日志中的消息。许多用户在遇到问题后没有尽快这样做而浪费了时间。
如果您无法从错误日志中判断问题出在哪里，请尝试以下技术：
SHOW MASTER STATUS通过发出语句 验证源是否启用了二进制日志记录 。如果启用日志记录，Position则为非零。如果未启用二进制日志记录，请验证您是否正在使用该--log-bin选项运行源服务器。验证
server_id系统变量是否在启动时在源和副本上设置，并且 ID 值在每台服务器上都是唯一的。验证副本是否正在运行。用于
SHOW SLAVE STATUS检查Slave_IO_Running和 的Slave_SQL_Running值是否都是Yes. 如果不是，请验证启动副本服务器时使用的选项。例如，--skip-slave-start在您发出START SLAVE语句之前阻止副本线程启动。如果副本正在运行，请检查它是否建立了与源的连接。使用
SHOW PROCESSLIST，找到 I/O 和 SQL 线程并检查它们的State列以查看它们显示的内容。请参阅 第 16.2.3 节，“复制线程”。如果复制 I/O 线程状态Connecting to master显示 ，请检查以下内容：验证用于在源上进行复制的用户的权限。
检查源的主机名是否正确，以及您是否使用正确的端口连接到源。用于复制的端口与用于客户端网络通信的端口相同（默认为
3306）。对于主机名，确保该名称解析为正确的 IP 地址。检查配置文件以查看
skip_networking系统变量是否已在源或副本上启用以禁用网络。如果是这样，请评论该设置或将其删除。如果源有防火墙或 IP 过滤配置，请确保用于 MySQL 的网络端口未被过滤。
检查您是否可以通过使用
ping或traceroute/tracert到达主机来到达源。
如果副本之前正在运行但已停止，原因通常是某些在源上成功的语句在副本上失败。如果您已经对源进行了适当的快照，并且从未在复制线程之外修改副本上的数据，那么这种情况永远不会发生。如果副本意外停止，这是一个错误，或者您遇到了第 16.4.1 节“复制功能和问题”中描述的已知复制限制之一。如果它是错误，请参阅 第 16.4.5 节，“如何报告复制错误或问题”，以获取有关如何报告它的说明。
如果在源上成功的语句拒绝在副本上运行，如果通过删除副本的数据库并从源复制新快照来执行完整的数据库重新同步不可行，请尝试以下过程：
确定副本上受影响的表是否与源上的表不同。试着理解这是怎么发生的。然后使副本表与源表相同并运行
START SLAVE。如果前面的步骤不起作用或不适用，请尝试了解手动进行更新（如果需要）是否安全，然后忽略来自源的下一条语句。
如果您决定副本可以跳过源中的下一条语句，请发出以下语句：
mysql> SET GLOBAL sql_slave_skip_counter = N; mysql> START SLAVE;N如果源中的下一条语句不使用AUTO_INCREMENTor ，则 的值应为 1LAST_INSERT_ID()。否则，该值应为 2。对于使用AUTO_INCREMENTor 的语句使用值 2 的原因LAST_INSERT_ID()是它们在源的二进制日志中获取两个事件。如果您确定副本开始时与源完全同步，并且没有人更新复制线程之外涉及的表，那么可能是错误导致的差异。如果您运行的是最新版本的 MySQL，请报告问题。如果您运行的是旧版本，请尝试升级到最新的生产版本以确定问题是否仍然存在。