MySQL GTID主備不一致的修復(fù)方案
方案一：重建 Replicas
MySQL 5.6及以上版在復(fù)制中引入了新的全局事務(wù)ID（GTID）支持。 在啟用了GTID模式的情況下執(zhí)行MySQL和MySQL 5.7的備份時，Percona XtraBackup會自動將GTID值存儲在xtrabackup_binlog_info中。 該信息可用于創(chuàng)建新的（或修復(fù)損壞的）基于GTID的副本。
前提條件
MySQL 機(jī)器上需要安裝 percona xtrabackup
優(yōu)點
比較安全，操作簡單
缺點
- 數(shù)據(jù)量較大的時候備份所需的時間比較久
- 當(dāng)數(shù)據(jù)庫有做讀寫分離的時候，Slave 承擔(dān)的讀請求需要轉(zhuǎn)移到 Master
操作步驟
Master
在 Master 上使用 xtrabackup 工具對當(dāng)前的數(shù)據(jù)庫進(jìn)行備份，執(zhí)行該命令的用戶需要有讀取 MySQL data 目錄的權(quán)限
innobackupex --default-file=/etc/my.cnf --user=root -H 127.0.0.1 --password=[PASSWORD] /tmp
將該備份文件拷貝到 Slave 機(jī)器上
Slave
在 Slave 機(jī)器上執(zhí)行該命令，準(zhǔn)備備份文件
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}
將備份拷貝到目標(biāo)目錄，并賦予相應(yīng)的權(quán)限，然后重啟 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
查看當(dāng)前備份已經(jīng)執(zhí)行過的最后一個的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，進(jìn)行如下配置
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 的復(fù)制狀態(tài)是否正常
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的新事務(wù)，因此從1到5的事務(wù)已在此副本上了。這樣我們就完成了一個新 replicas 的搭建。
方案二：使用percona-toolkit進(jìn)行數(shù)據(jù)修復(fù)
PT工具包中包含pt-table-checksum和pt-table-sync兩個工具，主要用于檢測主從是否一致以及修復(fù)數(shù)據(jù)不一致情況。
前提條件
MySQL 機(jī)器上需要安裝 percona-toolkit 工具
優(yōu)點
修復(fù)速度快，不需要停止從庫
缺點
操作復(fù)雜，操作前最后先備份數(shù)據(jù)庫
待修復(fù)的表需要具有 unique constraint
操作步驟
背景示例
IP 關(guān)系對應(yīng)
| IP | Role | | ---- | ---- | | 192.168.100.132 | Master | | 192.168.100.131 | Slave |
假設(shè)待恢復(fù)的表結(jié)構(gòu)如下所示
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 的數(shù)據(jù)均為如下所示
mysql> select * from test.t; +----+---------+ | id | content | +----+---------+ | 1 | a | | 2 | b | +----+---------+ 2 rows in set (0.00 sec)
在極端情況下，假如出現(xiàn)了如下主備不一致的情況，情形如下：
- Master 新增了一條 id 為 3 的記錄，如下所示，但并沒有同步到 Slave，同時自動 failover 到了 Slave。
- Old Slave 作為 New Master 在服務(wù)了一段時間后，表中增加了新的記錄。
重新啟動 Old Master 后，Old Master的數(shù)據(jù)如下所示:
old_master> select * from test.t; +----+---------+ | id | content | +----+---------+ | 1 | a | | 2 | b | | 3 | c | +----+---------+ 3 rows in set (0.00 sec)
New Master 的數(shù)據(jù)如下所示:
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，則會報錯，比如出現(xiàn)如下報錯
...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 恢復(fù)成可以正常從 New Master 復(fù)制的狀態(tài)
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 上可以看到復(fù)制在正常進(jìn)行
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上執(zhí)行 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
雙向同步（同步操作會修改數(shù)據(jù)，操作前進(jìn)行數(shù)據(jù)備份）
在同步過程中，pt-table-sync 會在 Master 上進(jìn)行數(shù)據(jù)修改，pt-table-sync的參數(shù)作用如下
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 指定待執(zhí)行的數(shù)據(jù)庫 --bidirectional 為雙向同步 --conflict-column 對比該列當(dāng)沖突發(fā)生時 --conflict-comparison 沖突對比策略 --print 輸出對比結(jié)果 --dry-run 測試運行 --execute 執(zhí)行測試 # 左邊的DSN為 Slave # 右邊的DSN為 Master
這里我們指定—conflict-name='content'作為對比列，一般使用業(yè)務(wù)主鍵作為該列?？梢钥吹酱蛴〕隽舜龍?zhí)行的語句
[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');
接下來執(zhí)行語句
[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 上再次執(zhí)行數(shù)據(jù)對比，可以看到數(shù)據(jù)正常了
[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主備不一致的修復(fù)方案的詳細(xì)內(nèi)容，更多關(guān)于MySQL GTID主備不一致修復(fù)的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
MySQL日期和時間函數(shù)是MySQL中的一個重要組件,它提供了一些有用的函數(shù)來處理日期和時間數(shù)據(jù),這篇文章主要給大家介紹了關(guān)于MySQL中常用的一些日期和時間函數(shù),文中通過代碼介紹的非常詳細(xì),需要的朋友可以參考下2024-06-06
在MySQL 5.1中，MySQL AB引入了新的插件式存儲引擎體系結(jié)構(gòu)，允許將存儲引擎加載到正在運新的MySQL服務(wù)器中2012-11-11
mysql 8.0.16 winx64.zip安裝配置方法圖文教程
這篇文章主要為大家詳細(xì)介紹了mysql 8.0.16 winx64.zip安裝配置方法圖文教程，具有一定的參考價值，感興趣的小伙伴們可以參考一下2019-05-05
這篇文章主要介紹了MySQL如何使用union all獲得并集排序,文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下2020-03-03
MySQL5.7 group by新特性報錯1055的解決辦法
項目中本來使用的是mysql5.6進(jìn)行開發(fā)，切換到5.7之后，突然發(fā)現(xiàn)原來的一些sql運行都報錯，錯誤編碼1055，錯誤信息和sql_mode中的“only_full_group_by“有關(guān)。下面小編給大家分享下解決辦法2016-12-12
完美轉(zhuǎn)換MySQL的字符集 解決查看utf8源文件中的亂碼問題
本人轉(zhuǎn)換過好多數(shù)據(jù)了，也用過了好多的辦法，個人感覺最好用的就是使用MySQL命令導(dǎo)出導(dǎo)入中將字符集轉(zhuǎn)換過去2011-11-11
今天同事問了一個需求,就是將多行數(shù)據(jù)合并成一行進(jìn)行顯示,查詢了一些資料,這篇文章主要給大家介紹了關(guān)于使用SQL將多行記錄合并成一行的相關(guān)資料,需要的朋友可以參考下2022-09-09
這篇文章主要介紹了MySQL 實例無法啟動的問題分析及解決方法，幫助大家更好的理解和學(xué)習(xí)使用MySQL數(shù)據(jù)庫，感興趣的朋友可以了解下2021-03-03
MySQL 5.7.9 服務(wù)無法啟動-“NET HELPMSG 3534”的解決方法
這篇文章主要介紹了MySQL 5.7.9 服務(wù)無法啟動-“NET HELPMSG 3534”的解決方法,需要的朋友可以參考下2016-12-12
這篇文章主要為大家詳細(xì)介紹了mysql 8.0.13 解壓版安裝配置方法圖文教程，具有一定的參考價值，感興趣的小伙伴們可以參考一下2018-11-11