1

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

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

M1 - M2 是多主复制设置，

S1 - 一个复制在 Master M1 上完成的写入的从站。

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

（S1机器上的M1故障检测机制），那么：

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

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

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

有没有更好的（更不容易出错）的方法来做到这一点？

谢谢

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

4

1 回答 1

1

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

仅使用 M2 所知道的当前 binlog 和位置是否更有意义？您需要检查 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 行）：从主机上执行的最后一个位置
  • 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它可能仍在增加一样。事实上，那些 Replication Coordinates 应该等于其他 Replication Coordinates (Master_Log_File,Read_Master_Log_Pos )。那时你就知道一切都被赶上了。如果这对复制坐标永远不会相遇，那么你应该多依赖Relay_Log_Space一点它何时停止增加。

怎么样Seconds_Behind_Master？

你不能使用的原因Seconds_Behind_Master很简单。一旦 Master 陷入困境，只需要一个 Replication 线程（Slave_IO_Running或Slave_SQL_Running）即可变为No并Seconds_Behind_Master转NULL。

于 2013-02-08T13:02:39.780 回答