MySQL GTID主備不一致的修復方案
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 mysqldmv /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/mysqlchown mysql.mysql -R /data/mysqlsystemctl start mysqld
查看當前備份已經執行過的最后一個的GTID，如下示例
$ cat /tmp/[TIMESTAMP]/xtrabackup_binlog_infomysql-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 STATUSG [..] 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)
在極端情況下，假如出現了如下主備不一致的情況，情形如下：
Master 新增了一條 id 為 3 的記錄，如下所示，但并沒有同步到 Slave，同時自動 failover 到了 Slave。 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 statusG*************************** 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-2541 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 skipQuery OK, 0 rows affected (0.00 sec)old_master> begin;Query OK, 0 rows affected (0.00 sec)old_master> commit; -- Inject an empty transactionQuery OK, 0 rows affected (0.00 sec)old_master> set gtid_next=’AUTOMATIC’； -- Restore to automaic GTIDQuery OK, 0 rows affected (0.00 sec)old_master> start slave;Query OK, 0 rows affected (0.13 sec)
然后我們在 Old Master 上可以看到復制在正常進行
mysql> show slave statusG ... Slave_IO_Running: Yes Slave_SQL_Running: Yes ... Executed_Gtid_Set: 5b750c75-86c2-11eb-af71-000c2973a2d5:1-10,60d082ee-86c2-11eb-a9df-000c2988edab:1-255Auto_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 statusG;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 testChecking if all tables can be checksummed ...Starting checksum ... TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE03-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 testChecking if all tables can be checksummed ...Starting checksum ... TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE03-30T12:09:57 0 0 4 0 1 0 0.330 test.t
以上就是MySQL GTID主備不一致的修復方案的詳細內容，更多關于MySQL GTID主備不一致修復的資料請關注好吧啦網其它相關文章！
相關文章：
網公網安備