MySQL复制:故障转移方案

Question

我有以下MySQL实例以及复制设置：

S1 - (M1 <-> M2)，其中：

M1 - M2是一个多主复制设置，

S1 --一个复制在主M1上完成的写入的从属程序。

现在，我正在尝试使用通道故障转移机制来增强设置，在此机制下，S1将开始从M2复制，如果M1关闭。目前，我看到的唯一办法是：

(M1故障检测机制在S1机器上)，然后：

-> S1从本地中继日志文件中获取M1查询的最新时间戳。

-> M2搜索本地binlog文件+ binlog索引 (bash脚本使用mysqlbinlog实用工具)，该文件对应于s1的最新时间戳。

-> S1最终可以执行“停止从”、“将主程序更改为master_host=M2.master_log_file=.master_log_pos=.”等命令，以继续复制，但这次是从M2执行的。

有没有一种更好(更少出错)的方法来做到这一点？

谢谢

编辑：现在，由于公开访问的MySQL集群解决方案通常使用的惟一Xid binlog查询标记，这要容易得多。

Answer 1

有一种更简单的方法来检索所需的binlog和位置。

就像M2所知道的那样，仅仅使用当前的二进制日志和位置会更有意义吗？您需要在M2上检查奴隶状态。

示例

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.51.130
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000463
          Read_Master_Log_Pos: 453865699
               Relay_Log_File: relay-bin.001226
                Relay_Log_Pos: 453865845
        Relay_Master_Log_File: mysql-bin.000463
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: search_cache
           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: 453865699
              Relay_Log_Space: 453866038
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 106451130
1 row in set (0.00 sec)

mysql>

对于这个显示器，有五个关键的组件：

• Master_Log_File (第6行)：最后读取其位置的母版上的日志文件
• Read_Master_Log_Pos (第7行)：从主人那里读到奴隶的最后位置
• Relay_Master_Log_File (第10行)：最后执行其位置的母版上的日志文件
• Exec_Master_Log_Pos (第22行)：在主服务器上执行的最后一个位置
• Relay_Log_Space (第23行)：所有中继日志的字节之和

Relay_Log_Space

请注意Relay_Log_Space。一旦这个数字停止递增，将读取从Master导入的每个SQL语句。不幸的是，最后一个中继日志可能由于突然的故障转移而损坏或简单地不完整。

Replication Coordinates

还请注意复制坐标(Relay_Master_Log_File, Exec_Master_Log_Pos)。这就是你要找的位置。然而，与Relay_Log_Space一样，它可能仍在增加。实际上，这些复制坐标应该等于其他复制坐标(Master_Log_File,Read_Master_Log_Pos )。那时你就知道所有的事情都被缠住了。如果这对复制坐标从未满足，那么您应该更多地依赖于Relay_Log_Space，因为它在什么时候停止递增。

那Seconds_Behind_Master呢？

不能使用Seconds_Behind_Master的原因很简单。一旦一个主服务器陷入困境，只需一个复制线程(Slave_IO_Running或Slave_SQL_Running)就能变成No，Seconds_Behind_Master就会变成NULL。