停电后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

看看主机上的回收站日志，我们有：

-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. 从状态显示，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

我选择了第一个选择。

这导致奴隶开始尝试执行与主键冲突的插入操作。正如前面提到的，奴隶所做的工作比主bin-log所坚持的要多。我没有预料到的一个方面是，奴隶包含不在主服务器中的数据；也就是说，在主服务器没有持久的断电之前，奴隶坚持了一些事务。

因为就我的情况而言，这些事务与支付无关或类似，所以我选择从从服务器中删除数据(因此丢失了一些已发生的数据，但这些数据在主服务器中不存在)，然后让复制再次运行。这使奴隶们完全跟上了时代。如果数据是更重要的，我们有足够的自动增量偏移，给我们一些扭动空间，手动纠缠数据，并确保参考完整性不受损害。谢天谢地，在这种情况下，我们不需要这样做。

对于处于这种困境中的(被动)主机配置中的机器，我选择了一种类似的方法。所谓被动主-母版，我的意思是我们有一个主动主(serverA)，它是所有写的地方，以及一个被动的主(serverB)，它允许模式更新在零停机时间内进行。active master (serverA)中的数据被选择为真正的值，尽管我们知道这意味着我们丢失了一些被认为不重要的持久化事务。

• 更改了日志文件和从服务器上的位置。更改主母版_LOG_FILE=‘bin-log.004713’，MASTER_LOG_POS=0；- on serverB
• 在被动主(serverB)上重新启动从复制，直到它与其他从服务器一样，在主键约束冲突中失败。启动从服务器；-在serverB上
• 停止从被动主(serverB)到主动主(serverA)的从复制。停止奴隶；-在serverA上
• 删除从站(serverB)上的行，这些行在serverA上的主服务器中不存在。从SOME_TABLE中删除ID IN (？？，？)；-在serverB上显示主日志状态\G；-在serverB上获取新的主日志位置
• 移动active master (serverA)从exec位置，以跳过被动母版(serverB)中的删除。将母版更改为MASTER_LOG_POS=？；-on serverA；使用刚刚从serverB获得的值
• 在活动主机(serverA)和被动主服务器上重新启动复制。启动奴隶；-在这两台机器上。serverA什么也不做，serverB开始迎头赶上。

Answer 2

这将取决于奴隶是主人的复制品有多重要。你的第一个选择将在一定程度上起作用，但奴隶很可能丢失了主人的信息。如果你能接受这一点，因为数据是短暂的或者其他什么的，那就去做吧。如果奴隶是正确的复制品是很重要的，那么第二个选项可能是您唯一的选择。不幸的是，MySQL复制对任何类型的意外中断都不友好，我发现这种问题比我想要的复制体系结构更频繁。