MySQL主從不一致的修復過程
昨天發現一個5.7的MySQL從庫在應用日誌的時候報出了錯誤。從庫啟用過了並行複製。Last Error的內容為:
Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction '8fc8d9ac-a62b-11e6-a3ee-a4badb1b4a00:7649' at master log mysql-bin.000011, end_log_pos 5290535. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
對於這類問題看起來還是比較陌生,如果想檢視一些明細的資訊,可以到binlog裡面看到一些。此處的relay log是teststd-relay-bin.000013
/usr/local/mysql/bin/mysqlbinlog --no-defaults --base64-output=DECODE-ROWS --verbose teststd-relay-bin.000013 > /tmp/mysqlbin.log
而修復方式和常規的略有一些差別。
STOP SLAVE;
SET @@SESSION.GTID_NEXT = '8fc8d9ac-a62b-11e6-a3ee-a4badb1b4a00:7649';
BEGIN; COMMIT;
SET @@SESSION.GTID_NEXT = AUTOMATIC;
START SLAVE;
然後再次應用,不過我發現我這列碰到的問題貌似比想象的要麻煩一些。可以從錯誤日誌看出是在更修改backend資料庫的表sys_user_audit的時候丟擲了錯誤。
2016-11-29T00:03:58.754386+08:00 161 [Note] Slave SQL thread for channel
'' initialized, starting replication in log 'mysql-bin.000011' at
position 5290028, relay log './teststd-relay-bin.000013' position: 27175
2016-11-29T00:03:58.754987+08:00 162 [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '8fc8d9ac-a62b-11e6-a3ee-a4badb1b4a00:7649' at master log mysql-bin.000011, end_log_pos 5290535; Could not execute Update_rows event on table backend.sys_user_audit; Can't find record in 'sys_user_audit', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log FIRST, end_log_pos 5290535, Error_code: 1032
手工跳過了幾次之後,發現這樣也不是事兒,如果這樣的問題較多,可以直接修改引數slave_exec_mode來完成。
set global slave_exec_mode=IDEMPOTENT;
當然這種方式解決當前問題還是比較合適的,跟上了主庫的變更,重新設定為原值。
set global slave_exec_mode=STRICT;很快從庫的狀態就正常了,但是又一個新的問題又來了。主從資料庫的資料怎麼不一致了。而且更加直接的是我對這個表在主從做了對比,發現資料是不一致的,從庫的資料比主庫少了9條。如此一來,這個從庫就是不合格的。
怎麼修復資料呢,一種直接的方式就是重建從庫,但是這樣不是一個很好的方案。還有其它的方案嗎,使用navicator也是一個不錯的方案,圖形介面點點配配就可以完成。還有一種方案是使用pt工具來修復。
早就耳聞,今天終於感受了一下。
首先安裝很常規,可以參考我之前的一篇文章。Percona-toolkit的安裝和配置(r8筆記第86天)其實就是下載解壓,基本的安裝。
在主從庫各建立一個臨時作為同步的使用者,先做checksum,然後根據checksum的情況來修復資料,這樣就涉及兩個命令列工具,pt-table-checksum和 pt-table-sync,當然這兩個工具的選項很多,我只做一些基本的操作。
建立使用者的方式如下,需要做對比主從checksum的資料庫為backend
GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'pt_checksum'@'10.127.%.%' IDENTIFIED BY 'pt_checksum';
建立的臨時資料庫為percona,也需要賦予相應的許可權。
grant all on percona.* to 'pt_checksum'@'10.127.%.%' ;
checksum的過程其實很複雜,大體有一下的步驟,當然我們可以簡化一下,達到目標然後再深究。
在主庫端開始做checksum,如果碰到下面的錯誤。
# pt-table-checksum
h='10.127.128.99',u='pt_checksum',p='pt_checksum',P=3306 -d backend
--nocheck-replication-filters --replicate=percona.checksums
Replica teststd.test.com has binlog_format ROW which could cause pt-table-checksum to break replication. Please read "Replicas using row-based replication" in the LIMITATIONS section of the tool's documentation. If you understand the risks, specify --no-check-binlog-format to disable this check.
這個選項的具體含義後續再琢磨,在row模式下會有這種警告,可以忽略這項檢查。
[root@testdb2 bin]# pt-table-checksum
h='10.127.128.99',u='pt_checksum',p='pt_checksum',P=3306 -d backend
--nocheck-replication-filters --replicate=percona.checksums
--no-check-binlog-format
TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
11-29T17:45:34 0 0 105 1 0 0.017 backend.sys_resource
11-29T17:45:34 0 0 17 1 0 0.015 backend.sys_role
11-29T17:45:34 0 1 99 1 0 0.017 backend.sys_user
11-29T17:45:34 0 1 172 1 0 0.017 backend.sys_user_audit
完成之後,在percona下會就生成一個表,裡面的資料就是一些對比的後設資料,如果存在差別則會有diffs欄位會有標示
如果確認無誤,可以開始修復資料,藉助pt-table-sync,先把SQL輸出不執行,把主庫和從庫的資訊都正確輸入。
pt-table-sync --print --replicate=percona.checksums h=10.127.128.99,u=pt_checksum,p=pt_checksum,P=3306 h=10.127.130.58,u=pt_checksum,p=pt_checksum,P=3306
而這個操作的原理其實就是replace into。
REPLACE INTO `backend`.`sys_user`(`id`, `user_name`, xxxx) VALUES ('100', 'songlijiao@test-inc.com', 'songlijiao', xxxxx) /*percona-toolkit src_db:backend src_tbl:sys_user src_dsn:P=3306,h=10.127.128.99,p=...,u=pt_checksum dst_db:backend dst_tbl:sys_user dst_dsn:P=3306,h=teststd.test.com,p=...,u=pt_checksum lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:28684 user:root host:testdb2.test.com*/;
切記要注意許可權,對於這個同步資料的使用者要開通操作目標資料庫的許可權。
grant insert,delete,update,select on backend.* to 'pt_checksum'@'10.127.%.%' ;
這個過程持續的時間不長,很快就能夠執行完畢,修復之後再次做checksum就完全正常了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2129342/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL主從修復MySql
- 【MySQL】主從GTID複製修復MySql
- MYSQL 主從不一致的原因分析MySql
- MySQL GTID複製中斷修復過程MySql
- MySQL主從複製的詳細過程介紹MySql
- MySQL恢復過程MySql
- MySQL MGR如何修復資料不一致的節點MySql
- Linux下MySQL主從複製(Binlog)的部署過程LinuxMySql
- 【MySQL】表索引損壞致Crash及修復過程一則MySql索引
- MySQL主從複製歷程MySql
- mysql ab主從複製出錯及解決過程MySql
- redis建立主從複製的過程Redis
- 《MySQL主從不一致情形與解決方法》MySql
- MySQL主從不一致情形與解決方法MySql
- MySQL主從資料不一致,怎麼辦?MySql
- MySQL資料庫INNODB表損壞修復處理過程分享MySql資料庫
- 檔案系統修復的一個過程
- mysql主從跳過錯誤MySql
- MySQL 主從 AUTO_INCREMENT 不一致問題分析MySqlREM
- mysql雙寫造成主從資料不一致的實驗MySql
- MySQL 崩潰恢復過程分析MySql
- MySQL主從複製不一致的情況的問題總結MySql
- redis cluster 故障後,主從位於不同節點的修復。Redis
- tinker熱修復——dex補丁載入過程
- mysql5.6搭建主從過程中遇到主從server_uuid一致無法同步的問題MySqlServerUI
- MySQL主主複製(雙主複製)配置過程介紹MySql
- MySQL Xtrabackup真實生產環境搭建主從複製全過程MySql
- 【mysql】mysql的資料庫主從(一主一從)MySql資料庫
- dataguard主庫壞塊的修復
- 儲存過程在主從庫上的測試儲存過程
- MySQL主從複製_複製過濾MySql
- pt-table-checksum校驗主從一致性,使用pt-table-sync修復資料不一致
- tinker熱修復——資源補丁載入過程
- Oracle後設資料物件Invalid修復過程Oracle物件
- 如何解決MySQL 主從複製資料不一致問題MySql
- MySQL的主從複製與MySQL的主主複製MySql
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- MySQL主從MySql