停电后 MySQL 复制问题

Question

在我们的数据中心断电后，从属 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

查看 master 上的 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

1. Slave 状态显示 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 都是 724207814，然后是二进制日志 bin-log.004712。我的理解是这个值是二进制日志文件中的字节位置。
2. bin-log.004712 文件只有 724200412 字节，所以从服务器认为他们完成的工作比实际保存在文件中的工作多 7402 字节（在 ext3 fs、RAID-10、RHEL5 上）。因此，有关不可能的日志位置等的错误消息。

修复奴隶的最佳方法是什么？

我正在考虑的选项：

1. 将每个从站设置为指向下一个 bin-log 文件 (bin-log.004713) 中的位置 0 并让它们离开，但我不确定这有多安全，或者可能会丢失多少数据。
2. 我是否需要进行完整备份和恢复（假设因 InnoDB 表上的表锁定而导致停机）？如果可能的话，我想避免这种情况。

更新：

我错过了另一个选项：将每个从属执行位置指向后一点，以便它尝试复制它已经从 bin-log.004712 处理过的命令。

Answer 1

我选择了第一个选择。

直到从属设备开始尝试执行与主键冲突的插入操作为止。如前所述，从站完成的工作比主站二进制日志所保留的工作还要多。我没有预料到的一个方面是从属设备包含主设备中没有的数据；即从属设备在断电之前保留了一些主设备未保留的事务。

由于就我而言，这些交易与支付无关或类似，因此我选择从从属服务器中删除数据（从而丢失一些已发生但主服务器中不存在的数据），然后让复制再次运行。这使奴隶们完全跟上时代的步伐。如果数据更重要，我们有足够的自动增量偏移量来为我们手动调整数据并确保引用完整性不受到损害提供一些回旋余地。值得庆幸的是，在这种情况下我们不需要这样做。

对于处于这种困境的（被动）主-主配置的机器，我选择了类似的方法。通过被动主控，我的意思是我们有一个主动主控（服务器 A），它是所有写入操作的所在，还有一个被动主控（服务器 B），它允许在零停机时间内进行架构更新。尽管知道这意味着我们丢失了一些不重要的持久事务，但仍选择活动主服务器（服务器 A）中的数据作为真实值。

• 更改了从站上的日志文件和位置。

  CHANGE MASTER MASTER_LOG_FILE='bin-log.004713', MASTER_LOG_POS=0; -- on serverB
  

• 在被动主服务器 (serverB) 上重新启动从服务器复制，直到它因违反主键约束而失败，与其他从服务器一样。

   START SLAVE; -- on serverB
  

• 停止从被动主服务器 (serverB) 到主动主服务器 (serverA) 的从属复制。

  STOP SLAVE; -- on serverA
  

• 删除从属服务器 (serverB) 上不存在于服务器 A 的主服务器中的行。

  DELETE FROM SOME_TABLE WHERE ID IN (???,????); -- on serverB
  SHOW MASTER STATUS\G; -- get the new master log position on serverB
  

• 移动主动主服务器 (serverA) 从属执行位置以跳过被动主服务器 (serverB) 中的删除操作。

  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.