对复制进行故障排除

如果您已按照说明进行操作，但复制设置无效，则要做的第一件事是检查错误日志中的message。许多用户由于在遇到问题后没有足够快地执行此操作而浪费了时间。
如果您无法从错误日志中找出问题所在，请尝试以下方法：
通过发出一条SHOW MASTER STATUS语句，验证主服务器是否启用了二进制日志记录。默认情况下启用二进制日志记录。如果启用了二进制日志记录，Position则为非零。如果未启用二进制日志记录，请验证您是否正在使用任何禁用二进制日志记录的设置（例如该--skip-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列以参见它们显示的内容。请参见“复制实现细节”。如果I / O线程状态为Connecting to master，请检查以下内容：
在主服务器上验证用于复制的用户的特权。
检查主服务器的主机名正确，并且使用正确的端口连接到主服务器。用于复制的端口与用于客户端网络通信的端口相同（默认为3306）。对于主机名，请确保该名称解析为正确的IP地址。
检查配置文件以参见是否skip_networking在主服务器或从服务器上启用了系统变量以禁用网络。如果是这样，请注释该设置或将其删除。
如果主服务器具有防火墙或IP过滤配置，请确保未过滤用于MySQL的网络端口。
通过使用ping或traceroute/tracert来访问主机，检查您是否可以访问主机。
如果从属服务器以前运行但已停止，则通常是由于在主服务器上成功执行的某些语句在从属服务器上失败了。如果您已对主服务器进行了适当的快照，并且从未在从属线程之外修改从属服务器上的数据，则永远不会发生这种情况。如果从服务器意外停止，则可能是错误，或者您遇到了“复制功能和问题”中所述的已知复制限制之一。如果是错误，请参见“如何报告复制错误或问题”，以获取有关如何报告该错误的说明。
如果在主服务器上成功执行的语句拒绝在从服务器上运行，请执行以下过程，如果通过删除从服务器的数据库并从主服务器复制新快照来进行完全数据库重新同步是不可行的：
确定从属服务器上受影响的表是否与主表不同。尝试了解这是怎么发生的。然后，使从服务器的表与主服务器的表相同，然后运行START SLAVE。
如果前面的步骤不起作用或不适用，请尝试了解手动进行更新是否安全（如果需要），然后忽略主服务器的下一条语句。
如果您确定从站可以跳过主站的下一条语句，请发出以下语句：
mysql> SET GLOBAL sql_slave_skip_counter = N;
mysql> START SLAVE;
N如果主服务器的下一条语句不使用AUTO_INCREMENT或，则值应为1 LAST_INSERT_ID()。否则，该值应为2。之所以对使用AUTO_INCREMENT或的语句使用2值，LAST_INSERT_ID()是因为它们在主数据库的二进制日志中包含两个事件。
另请参见“ SET GLOBAL sql_slave_skip_counter语句”。
如果您确定从属服务器开始时与主服务器完全同步，并且没有人更新过从属服务器线程之外的表，则可能是由于错误引起的。如果您正在运行最新版本的MySQL，请报告该问题。如果运行的是旧版本，请尝试升级到最新的生产版本，以确定问题是否仍然存在。