我们的数据中心断电后，从属 MySQL 数据库陷入困境。
这是其中一个从属服务器的日志：
100118 10:05:56 [Note] Slave I/O thread: connected to master 'repl@db1:3306', replication started in log 'bin-log.004712' at position 724207814
100118 10:05:56 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100118 10:05:56 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
100118 10:05:56 [Note] Slave I/O thread exiting, read up to log 'bin-log.004712', position 724207814
控制台显示了更多细节：
mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: db1
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: bin-log.004712
Read_Master_Log_Pos: 724207814
Relay_Log_File: mysqld-relay-bin.000105
Relay_Log_Pos: 98
Relay_Master_Log_File: bin-log.004712
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB: mmplive1,mmpjcr,fui
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: 724207814
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
查看主服务器上的 bin 日志，我们发现：
-rw-rw---- 1 mysql mysql 724200412 Jan 18 09:22 bin-log.004712
-rw-rw---- 1 mysql mysql 1904 Jan 18 09:27 bin-log.index
-rw-rw---- 1 mysql mysql 5046830 Jan 18 11:22 slow-log
-rw-rw---- 1 mysql mysql 198249613 Jan 18 11:24 bin-log.004713
- Slave 状态显示 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 均为 724207814，二进制日志为 bin-log.004712。我的理解是，该值是二进制日志文件中的字节位置。
- 该 bin-log.004712 文件只有 724200412 字节，因此从属服务器认为它们所做的工作比实际保存在文件中的工作多 7402 字节（该文件位于 ext3 fs、RAID-10、RHEL5 上）。因此会出现有关不可能的日志位置等的错误消息。
修复奴隶的最佳方法是什么？
我正在考虑的选项：
- 将每个从属服务器设置为指向下一个 bin-log 文件 (bin-log.004713) 中的位置 0，然后让它们运行，但我不确定这样做有多安全，或者可能会丢失多少数据。
- 我是否需要进行完整备份和恢复（由于 InnoDB 表上的表锁，可能会有相关的停机时间）？如果可能的话，我想避免这种情况。
更新：
我错过了另一个选项：将每个从属执行位置稍微往后指，以便它会尝试复制已经从 bin-log.004712 处理过的命令。
答案1
我选择了第一个选项。
直到从服务器开始尝试执行与主键冲突的插入操作时，该操作才起作用。如前所述，从服务器完成的工作比主服务器的 bin-log 持久化的工作要多。我没有预料到的一个方面是，从服务器包含主服务器中没有的数据；即，在主服务器断电之前，从服务器持久化了一些事务没有坚持。
由于就我的情况而言，这些交易与付款无关或类似，因此我选择从从服务器中删除数据（从而丢失一些已发生但主服务器中不存在的数据），然后让复制再次运行。这使从服务器完全保持最新状态。如果数据更重要，我们有自动增加的偏移量，足以为我们提供一些回旋余地来手动处理数据并确保引用完整性不受影响。幸运的是，在这种情况下我们不需要这样做。
对于处于这种困境的（被动）主-主配置的机器，我选择了类似的方法。被动主-主是指我们有一个主动主服务器（服务器 A），所有写入都在此进行，还有一个被动主服务器（服务器 B），允许在零停机时间内进行架构更新。主动主服务器（服务器 A）中的数据被选为真实值，尽管我们知道这意味着我们会丢失一些不重要的持久事务。
更改了从属服务器上的日志文件和位置。
CHANGE MASTER MASTER_LOG_FILE='bin-log.004713', MASTER_LOG_POS=0; -- on serverB重新启动被动主服务器（serverB）上的从属复制，直到它因主键约束违规而失败，就像其他从属服务器一样。
START SLAVE; -- on serverB停止从被动主服务器（服务器 B）到主动主服务器（服务器 A）的从属复制。
STOP SLAVE; -- on serverA删除从服务器（服务器B）上在服务器A的主服务器上不存在的行。
DELETE FROM SOME_TABLE WHERE ID IN (???,????); -- on serverB SHOW MASTER STATUS\G; -- get the new master log position on serverB移动主动主服务器（服务器A）从属执行位置以跳过来自被动主服务器（服务器B）的那些删除。
CHANGE MASTER TO MASTER_LOG_POS=???; --on serverA; use the value just obtained from serverB在主动主服务器（serverA）和被动主服务器上重新启动复制。
START SLAVE; -- on both machines. serverA does nothing and serverB starts catching up.
答案2
这取决于从服务器是否是主服务器的精确副本有多重要。您的第一个选项在一定程度上可行，但从服务器很可能缺少主服务器的信息。如果您可以忍受这种情况，因为数据是瞬态的，那么就去做吧。如果从服务器是否是适当的副本很重要，那么第二个选项可能是您唯一的选择。不幸的是，MySQL 复制不能容忍任何类型的意外中断，我发现这类问题在我的复制架构中比我希望的要频繁得多。