共計 4118 個字符，預計需要花費 11 分鐘才能閱讀完成。
本篇文章給大家分享的是有關 MySQL 主從不一致的修復過程是怎樣的，丸趣 TV 小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。
昨天發(fā)現一個 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
而修復方式和常規(guī)的略有一些差別。
STOP SLAVE;
SET @@SESSION.GTID_NEXT = 8fc8d9ac-a62b-11e6-a3ee-a4badb1b4a00:7649
BEGIN; COMMIT;
SET @@SESSION.GTID_NEXT = AUTOMATIC;
START SLAVE;
然后再次應用，不過我發(fā)現我這列碰到的問題貌似比想象的要麻煩一些。可以從錯誤日志看出是在更修改 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
手工跳過了幾次之后，發(fā)現這樣也不是事兒，如果這樣的問題較多，可以直接修改參數 slave_exec_mode 來完成。
set global slave_exec_mode=IDEMPOTENT;
當然這種方式解決當前問題還是比較合適的，跟上了主庫的變更，重新設置為原值。
set global slave_exec_mode=STRICT; 很快從庫的狀態(tài)就正常了，但是又一個新的問題又來了。主從數據庫的數據怎么不一致了。而且更加直接的是我對這個表在主從做了對比，發(fā)現數據是不一致的，從庫的數據比主庫少了 9 條。如此一來，這個從庫就是不合格的。
怎么修復數據呢，一種直接的方式就是重建從庫，但是這樣不是一個很好的方案。還有其它的方案嗎，使用 navicator 也是一個不錯的方案，圖形界面點點配配就可以完成。還有一種方案是使用 pt 工具來修復。
早就耳聞，今天終于感受了一下。
首先安裝很常規(guī)，可以參考我之前的一篇文章。Percona-toolkit 的安裝和配置 (r8 筆記第 86 天）其實就是下載解壓，基本的安裝。
在主從庫各創(chuàng)建一個臨時作為同步的用戶，先做 checksum，然后根據 checksum 的情況來修復數據，這樣就涉及兩個命令行工具，pt-table-checksum 和 pt-table-sync，當然這兩個工具的選項很多，我只做一些基本的操作。
創(chuàng)建用戶的方式如下，需要做對比主從 checksum 的數據庫為 backend
GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO pt_checksum @ 10.127.%.% IDENTIFIED BY pt_checksum
創(chuàng)建的臨時數據庫為 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.
這個選項的具體含義后續(xù)再琢磨，在 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 輸出不執(zhí)行，把主庫和從庫的信息都正確輸入。
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.%.%
這個過程持續(xù)的時間不長，很快就能夠執(zhí)行完畢，修復之后再次做 checksum 就完全正常了。
以上就是 MySQL 主從不一致的修復過程是怎樣的，丸趣 TV 小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注丸趣 TV 行業(yè)資訊頻道。
