MySQL 复制 : failover scenario

Question

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

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

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

S1 - 复制在主 M1 上完成的写入的从站。

现在，我正在尝试使用 channel 故障转移机制来增强设置，如果 M1 出现故障，S1 将开始从 M2 进行复制。目前，我看到的唯一方法是:

(S1机器上的M1故障检测机制)，则:

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

-> M2 搜索(使用 mysqlbinlog 实用程序的 bash 脚本)本地 binlog 文件 + binlog 索引 对应于 S1 的最新时间戳

-> S1 终于可以执行“STOP SLAVE”、“CHANGE MASTER TO master_host=M2...master_log_file=...master_log_pos=...”等命令继续复制，但是这次从 M2

是否有更好(且更不容易出错)的方法来做到这一点？

谢谢

编辑:如今，由于可公开访问的 MySQL 集群解决方案通常使用独特的 Xid binlog 查询标签，这更容易实现。

Answer 1

有一种更简单的方法来检索所需的二进制日志和位置。

仅使用 M2 知道的当前二进制日志和位置是否更有意义？您需要检查 M2 上的 Slave 状态。

例子

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 行):最后读取其位置的 Master 上的日志文件
• Read_Master_Log_Pos(第 7 行):从主机读取的从机上的最后位置
• Relay_Master_Log_File(第 10 行):最后执行位置的 Master 上的日志文件
• Exec_Master_Log_Pos(第 22 行):Master 在 Slave 上执行的最后位置
• Relay_Log_Space(第 23 行):所有中继日志的字节总和

Relay_Log_Space

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

复制坐标

另请注意复制坐标(Relay_Master_Log_File, Exec_Master_Log_Pos)。这就是您正在寻找的职位。但是，与 Relay_Log_Space 一样，它可能仍在递增。事实上，那些复制坐标应该等于其他复制坐标(Master_Log_File,Read_Master_Log_Pos )。那是你知道一切都被 catch 的时候。如果这对复制坐标永远不会相遇，那么就停止递增的时间而言，您应该更多地依赖 Relay_Log_Space。

Seconds_Behind_Master 怎么样？

您不能使用 Seconds_Behind_Master 的原因很简单。一旦 Master 宕机，只需要一个复制线程(Slave_IO_Running 或 Slave_SQL_Running)就可以变成No 和 Seconds_Behind_Master 变为 NULL。