我们在我们的备份服务器上运行一个mysql复制客户端。 自上周停电以来，停止复制。 在此之前，它连续运行了好几个月。
我试过重新启动主和奴隶，但这并没有帮助。 我可以从奴隶访问主服务器，所以networking不是问题。
还有什么我可以做的，以尝试诊断问题是什么？
mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Master_Host: master Master_User: username Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000060 Read_Master_Log_Pos: 46277494 Relay_Log_File: mysqld-relay-bin.000348 Relay_Log_Pos: 98 Relay_Master_Log_File: mysql-bin.000060 Slave_IO_Running: No Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 46277494 Relay_Log_Space: 98 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL 1 row in set (0.00 sec) ERROR: No query specified mysql> show master status\G; *************************** 1. row *************************** File: mysql-bin.000069 Position: 851796 Binlog_Do_DB: Binlog_Ignore_DB: 1 row in set (0.00 sec) ERROR: No query specified 更新：错误进入daemon.log，而不是mysql.err，这将解释为什么我找不到它们。 问题似乎是主人说日志是不可用的，这没有多大意义，因为日志（和前一个日志）在主日志中仍然可用。
090710 9:17:35 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000060' at position 46277494, relay log './mysqld-relay-bin.000350' position: 98 090710 9:17:35 [Note] Slave I/O thread: connected to master 'username@master:3306', replication started in log 'mysql-bin.000060' at position 46277494 090710 9:17:35 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236) 090710 9:17:35 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log 090710 9:17:35 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000060', position 46277494
欢迎来到MySQL复制的奇妙世界。 我自己并没有遇到你特别的问题，但是我遇到了很多其他奇怪的问题，最接近的解决scheme就是和主人重新同步，就好像它是一个全新的奴隶一样。
你应该检查奴隶的错误日志 – 通常很明确的问题是什么。
你应该把mysql错误日志绑定到你的监控系统，否则你的奴隶可能是没有价值的。
此外，你应该有一个监视器，检查奴隶状态。
而为了任何使用，你还需要不时检查从机的同步，也许通过使用像mk-table-checksum; 理想情况下，也将这些结果与您的监测系统结合起来。
许多人设置skip-slave-start，以便在启动之前，如果从站停止复制，他们可以确保一切正常。 尝试运行“开始奴隶”，看看是否有任何更改或如果有logging。 另外奇怪的是，SlaveSQL进程正在运行，SlaveIO没有运行。 从站上的本地中继日志可能已经损坏，尽pipe应该在日志中报告。 你可以尝试把Mysqlclosures，然后删除中继日志。
正如womble提到的，忘记解决复制错误。 这种方法最让我担心的是，你可能会成功复制重新启动，并认为一切正常，但如果你的数据库的某些部分仍然不同步呢？
最好的办法是从属数据库的核心，并从主机的快照重新启动复制。 它不应该像你想象的那样具有破坏性：
http://www.neotitans.com/resources/mysql/quick-replication-error-recovery-via-snapshots.html
从上面的报告中我发现这个问题，必须设置为（Slave_IO_Running）：是的，但是在上面的报告中显示了Slave_IO_Running：否。
这是造成这个问题，如果这个variables读取“否”，那么IO线程被停止。 所以没有任何复制。 您将必须检查Last_SQL_Errno和Last_SQL_Err以获取有关原因的更多信息。 错误号为0，空string的消息表示“没有错误”。Last_SQL_Error出现在从站的错误日志中。
要解决这个问题，请停止从站
然后设置：
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
这告诉从机跳过一个查询（这是导致复制停止的无效查询）。 如果你想跳过两个查询，你可以使用SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; 反而等等。
然后重新启动从站，并检查日志，希望这将解决这个问题…