16.4.4 复制故障排除

如果您已按照说明进行操作，但复制设置无效，则要做的第一件事是检查错误日志中的消息。许多用户在遇到问题后没有足够的时间来浪费时间。

如果您无法从错误日志中找出问题所在，请尝试以下技术：

• 通过发出显示主状态语句，验证源已启用二进制日志记录。如果启用了日志记录，则Position为非零。如果未启用二进制日志记录，请使用--log-bin选项验证您正在运行源服务器。

• 验证在源和副本上都在启动时设置了server_id系统变量，并且 ID 值在每个服务器上都是唯一的。

• 验证副本正在运行。使用显示从站状态检查Slave_IO_Running和Slave_SQL_Running值是否均为Yes。如果不是，请验证启动副本服务器时使用的选项。例如，--skip-slave-start会阻止复制线程启动，直到您发出START SLAVE语句为止。

• 如果副本正在运行，请检查它是否构建了与源的连接。使用SHOW PROCESSLIST，找到 I/O 和 SQL 线程并检查其State列以查看它们显示的内容。参见第 16.2.2 节“复制实现的详细信息”。如果复制 I/O 线程状态为Connecting to master，请检查以下内容：

• 在源上验证用于复制的用户的特权。

  • 检查源的主机名正确，并且使用正确的端口连接到源。用于复制的端口与用于 Client 端网络通信的端口相同(默认为3306)。对于主机名，请确保该名称解析为正确的 IP 地址。

  • 检查配置文件以查看是否已在源或副本上启用skip_networking系统变量以禁用联网。如果是这样，请 Comments 该设置或将其删除。

  • 如果源具有防火墙或 IP 过滤配置，请确保未过滤用于 MySQL 的网络端口。

  • 通过使用ping或traceroute/tracert到达主机来检查是否可以到达源。

• 如果副本先前在运行但已停止，则通常是由于在源上成功执行的某些语句在副本上失败了。如果您已对源进行了适当的快照，并且从未在复制线程之外修改副本上的数据，则永远不会发生这种情况。如果副本意外停止，则 table 明它是一个错误，或者您遇到了第 16.4.1 节“复制功能和问题”中描述的已知复制限制之一。如果是错误，请参阅第 16.4.5 节“如何报告复制错误或问题”，以获取有关如何报告该错误的说明。

• 如果在源上成功执行的语句拒绝在副本上运行，请执行以下过程，如果通过删除副本数据库并从源复制新快照来执行完全数据库重新同步是不可行的：

• 确定副本上受影响的 table 是否与源上的 table 不同。尝试了解这是怎么发生的。然后，使副本的 table 与源的 table 相同，并运行START SLAVE。

• 如果前面的步骤不起作用或不适用，请尝试了解手动进行更新是否安全(如果需要)，然后忽略源中的下一条语句。

• 如果您确定副本可以跳过源中的下一条语句，请发出以下语句：

mysql> SET GLOBAL sql_slave_skip_counter = N;
mysql> START SLAVE;

如果源中的下一条语句不使用AUTO_INCREMENT或LAST_INSERT_ID()，则* N *的值应为 1.否则，该值应为 2.对于使用AUTO_INCREMENT或LAST_INSERT_ID()的语句使用值 2 的原因是，它们在源的二进制日志中记录了两个事件。

另请参见SET GLOBAL sql_slave_skip_counter 语句。

• 如果您确定副本开始时与源完全同步，并且没有人更新过复制线程之外的 table，则可能是由于错误引起的。如果您正在运行最新版本的 MySQL，请报告该问题。如果运行的是旧版本，请尝试升级到最新的生产版本，以确定问题是否仍然存在。