MySQL GTID主備不一致的修復方案

Posted on by

方案一：重建 Replicas

MySQL 5.6及以上版在復制中引入瞭新的全局事務ID（GTID）支持。 在啟用瞭GTID模式的情況下執行MySQL和MySQL 5.7的備份時，Percona XtraBackup會自動將GTID值存儲在xtrabackup_binlog_info中。 該信息可用於創建新的（或修復損壞的）基於GTID的副本。

前提條件

MySQL 機器上需要安裝 percona xtrabackup

優點

比較安全，操作簡單

缺點

  • 數據量較大的時候備份所需的時間比較久
  • 當數據庫有做讀寫分離的時候，Slave 承擔的讀請求需要轉移到 Master

操作步驟

Master

在 Master 上使用 xtrabackup 工具對當前的數據庫進行備份，執行該命令的用戶需要有讀取 MySQL data 目錄的權限

innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORD] /tmp

將該備份文件拷貝到 Slave 機器上

Slave

在 Slave 機器上執行該命令，準備備份文件

innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORD] --apply-log /tmp/[TIMESTAMP]

備份並刪除 Slave data目錄

systemctl stop mysqld
mv /data/mysql{,.bak}

將備份拷貝到目標目錄，並賦予相應的權限，然後重啟 Slave

innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORD] --copy-back /tmp/[TIMESTAMP]
chmod 750 /data/mysql
chown mysql.mysql -R /data/mysql
systemctl start mysqld

查看當前備份已經執行過的最後一個的GTID，如下示例

$ cat /tmp/[TIMESTAMP]/xtrabackup_binlog_info
mysql-bin.000002  1232    c777888a-b6df-11e2-a604-080027635ef5:1-4

這個GTID也會在 innobackupex 備份完成後打印出來

innobackupex: MySQL binlog position: filename 'mysql-bin.000002', position 1232, GTID of the last change 'c777888a-b6df-11e2-a604-080027635ef5:1-4'

使用 root 登錄 MySQL，進行如下配置

NewSlave > RESET MASTER;
NewSlave > SET GLOBAL gtid_purged='c777888a-b6df-11e2-a604-080027635ef5:1-4';
NewSlave > CHANGE MASTER TO
       MASTER_HOST="$masterip",
       MASTER_USER="repl",
       MASTER_PASSWORD="$slavepass",
       MASTER_AUTO_POSITION = 1;
NewSlave > START SLAVE;

查看 Slave 的復制狀態是否正常

NewSlave > SHOW SLAVE STATUS\G
     [..]
     Slave_IO_Running: Yes
     Slave_SQL_Running: Yes
     [...]
     Retrieved_Gtid_Set: c777888a-b6df-11e2-a604-080027635ef5:5
     Executed_Gtid_Set: c777888a-b6df-11e2-a604-080027635ef5:1-5

我們可以看到副本已檢索到編號為5的新事務，因此從1到5的事務已在此副本上瞭。這樣我們就完成瞭一個新 replicas 的搭建。

方案二：使用percona-toolkit進行數據修復

PT工具包中包含pt-table-checksum和pt-table-sync兩個工具，主要用於檢測主從是否一致以及修復數據不一致情況。

前提條件

MySQL 機器上需要安裝 percona-toolkit 工具

優點

修復速度快，不需要停止從庫

缺點

操作復雜，操作前最後先備份數據庫
待修復的表需要具有 unique constraint

操作步驟

背景示例

IP 關系對應

| IP | Role |
| ---- | ---- |
| 192.168.100.132 | Master |
| 192.168.100.131 | Slave |

假設待恢復的表結構如下所示

mysql> show create table test.t;
+-------+-------------------------------------
| Table | Create Table                                                                 |
+-------+-------------------------------------
| t   | CREATE TABLE `t` (
 `id` int(11) NOT NULL,
 `content` varchar(20) DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+-------+-------------------------------------

正常主備一致的情況下，Master 和 Slave 的數據均為如下所示

mysql> select * from test.t;
+----+---------+
| id | content |
+----+---------+
| 1 | a    |
| 2 | b    |
+----+---------+
2 rows in set (0.00 sec)

在極端情況下，假如出現瞭如下主備不一致的情況，情形如下：

  1. Master 新增瞭一條 id 為 3 的記錄，如下所示，但並沒有同步到 Slave，同時自動 failover 到瞭 Slave。
  2. Old Slave 作為 New Master 在服務瞭一段時間後，表中增加瞭新的記錄。

重新啟動 Old Master 後，Old Master的數據如下所示:

old_master> select * from test.t;
+----+---------+
| id | content |
+----+---------+
| 1 | a    |
| 2 | b    |
| 3 | c    |
+----+---------+
3 rows in set (0.00 sec)

New Master 的數據如下所示:

new_master> select * from test.t;
+----+---------+
| id | content |
+----+---------+
| 1 | a    |
| 2 | b    |
| 3 | cc   |
| 4 | dd   |
+----+---------+
4 rows in set (0.00 sec)

此時如果將 old master 配置為 new master 的slave，則會報錯，比如出現如下報錯

...Last_IO_Error: binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID.

可以看到 Old Master 的 GTID 已到 255

Executed_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-10,
60d082ee-86c2-11eb-a9df-000c2988edab:1-255

而 New Master 的 GTID才到254

mysql> show master status\G
*************************** 1. row ***************************
       File: mysql-bin.000001
     Position: 4062
   Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-2,
60d082ee-86c2-11eb-a9df-000c2988edab:1-254
1 row in set (0.00 sec)

此時我們配置 Old Master 跳過錯誤，將 Old Master 恢復成可以正常從 New Master 復制的狀態

old_master> stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

old_master> set gtid_next='60d082ee-86c2-11eb-a9df-000c2988edab:254'; --Specify the version of the next transaction,the GTID you want to skip
Query OK, 0 rows affected (0.00 sec)

old_master> begin;
Query OK, 0 rows affected (0.00 sec)

old_master> commit;                          -- Inject an empty transaction
Query OK, 0 rows affected (0.00 sec)

old_master> set gtid_next='AUTOMATIC'；  -- Restore to automaic GTID
Query OK, 0 rows affected (0.00 sec)

old_master> start slave;
Query OK, 0 rows affected (0.13 sec)

然後我們在 Old Master 上可以看到復制在正常進行

mysql> show slave status\G
      ...
       Slave_IO_Running: Yes
      Slave_SQL_Running: Yes
      ...
      Executed_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-10,
60d082ee-86c2-11eb-a9df-000c2988edab:1-255
        Auto_Position: 1
     Replicate_Rewrite_DB:
         Channel_Name:
      Master_TLS_Version:

最後我們在 New Master 上清除 slave_master_info

new_master> reset slave all for channel '';
Query OK, 0 rows affected (0.00 sec)

new_master> show slave status\G;
Empty set (0.01 sec)

校驗一致性

接下來我們要校驗主從一致性，在 New Master上執行 pt-table-checksum，ROWS為4，存在一條DIFFS

[root@localhost ~]# pt-table-checksum h='127.0.0.1',u='mha',p='[PASSWORD]',P=3306 --no-check-binlog-format --databases test
Checking if all tables can be checksummed ...
Starting checksum ...
      TS ERRORS DIFFS   ROWS DIFF_ROWS CHUNKS SKIPPED  TIME TABLE
03-29T19:24:18   0   1    4     1    1    0  0.322 test.t

雙向同步（同步操作會修改數據，操作前進行數據備份）

在同步過程中，pt-table-sync 會在 Master 上進行數據修改，pt-table-sync的參數作用如下

pt-table-sync --databases test --bidirectional --conflict-column='*' --conflict-comparison 'newest' h='192.168.100.132',u='mha',p='[PASSWORD]',P=3306 h='192.168.100.131' --print
--database        指定待執行的數據庫
--bidirectional      為雙向同步
--conflict-column     對比該列當沖突發生時
--conflict-comparison   沖突對比策略
--print          輸出對比結果
--dry-run         測試運行
--execute         執行測試

# 左邊的DSN為 Slave
# 右邊的DSN為 Master

這裡我們指定—conflict-name=’content’作為對比列，一般使用業務主鍵作為該列。可以看到打印出瞭待執行的語句

[root@localhost ~]# pt-table-sync --databases test --bidirectional --conflict-column='content' --conflict-comparison 'newest' h='192.168.100.132',u='mha',p='[PASSWORD]',P=3306 h='192.168.100.131' --print
/*192.168.100.132:3306*/ UPDATE `test`.`t` SET `content`='cc' WHERE `id`='3' LIMIT 1;
/*192.168.100.132:3306*/ INSERT INTO `test`.`t`(`id`, `content`) VALUES ('4', 'dd');

接下來執行語句

[root@localhost ~]# pt-table-sync --databases test --bidirectional --conflict-column='content' --conflict-comparison 'newest' h='192.168.100.132',u='mha',p='[PASSWORD]',P=3306 h='192.168.100.131' --execute

然後在 Master 上再次執行數據對比，可以看到數據正常瞭

[root@localhost ~]# pt-table-checksum h='127.0.0.1',u='mha',p='[PASSWORD]',P=3306 --no-check-binlog-format --databases test
Checking if all tables can be checksummed ...
Starting checksum ...
      TS ERRORS DIFFS   ROWS DIFF_ROWS CHUNKS SKIPPED  TIME TABLE
03-30T12:09:57   0   0    4     0    1    0  0.330 test.t

以上就是MySQL GTID主備不一致的修復方案的詳細內容，更多關於MySQL GTID主備不一致修復的資料請關註WalkonNet其它相關文章！

推薦閱讀：

    None Found