本篇文章給大家分享的是有關(guān)MySQL主從不一致的修復(fù)過(guò)程是怎樣的，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

成都創(chuàng)新互聯(lián)專(zhuān)注于企業(yè)成都全網(wǎng)營(yíng)銷(xiāo)推廣、網(wǎng)站重做改版、桂平網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5場(chǎng)景定制、成都商城網(wǎng)站開(kāi)發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為桂平等各大城市提供網(wǎng)站開(kāi)發(fā)制作服務(wù)。

昨天發(fā)現(xiàn)一個(gè)5.7的MySQL從庫(kù)在應(yīng)用日志的時(shí)候報(bào)出了錯(cuò)誤。從庫(kù)啟用過(guò)了并行復(fù)制。Last Error的內(nèi)容為：

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.

對(duì)于這類(lèi)問(wèn)題看起來(lái)還是比較陌生，如果想查看一些明細(xì)的信息，可以到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

而修復(fù)方式和常規(guī)的略有一些差別。

STOP SLAVE;
SET @@SESSION.GTID_NEXT = '8fc8d9ac-a62b-11e6-a3ee-a4badb1b4a00:7649';
BEGIN; COMMIT;
SET @@SESSION.GTID_NEXT = AUTOMATIC;
START SLAVE;

然后再次應(yīng)用，不過(guò)我發(fā)現(xiàn)我這列碰到的問(wèn)題貌似比想象的要麻煩一些?？梢詮腻e(cuò)誤日志看出是在更修改backend數(shù)據(jù)庫(kù)的表sys_user_audit的時(shí)候拋出了錯(cuò)誤。

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 

手工跳過(guò)了幾次之后，發(fā)現(xiàn)這樣也不是事兒，如果這樣的問(wèn)題較多，可以直接修改參數(shù)slave_exec_mode來(lái)完成。

set global slave_exec_mode=IDEMPOTENT;

當(dāng)然這種方式解決當(dāng)前問(wèn)題還是比較合適的，跟上了主庫(kù)的變更，重新設(shè)置為原值。

set global slave_exec_mode=STRICT;很快從庫(kù)的狀態(tài)就正常了，但是又一個(gè)新的問(wèn)題又來(lái)了。主從數(shù)據(jù)庫(kù)的數(shù)據(jù)怎么不一致了。而且更加直接的是我對(duì)這個(gè)表在主從做了對(duì)比，發(fā)現(xiàn)數(shù)據(jù)是不一致的，從庫(kù)的數(shù)據(jù)比主庫(kù)少了9條。如此一來(lái)，這個(gè)從庫(kù)就是不合格的。

怎么修復(fù)數(shù)據(jù)呢，一種直接的方式就是重建從庫(kù)，但是這樣不是一個(gè)很好的方案。還有其它的方案嗎，使用navicator也是一個(gè)不錯(cuò)的方案，圖形界面點(diǎn)點(diǎn)配配就可以完成。還有一種方案是使用pt工具來(lái)修復(fù)。

早就耳聞，今天終于感受了一下。

首先安裝很常規(guī)，可以參考我之前的一篇文章。Percona-toolkit的安裝和配置(r8筆記第86天）其實(shí)就是下載解壓，基本的安裝。

在主從庫(kù)各創(chuàng)建一個(gè)臨時(shí)作為同步的用戶，先做checksum，然后根據(jù)checksum的情況來(lái)修復(fù)數(shù)據(jù)，這樣就涉及兩個(gè)命令行工具，pt-table-checksum和 pt-table-sync，當(dāng)然這兩個(gè)工具的選項(xiàng)很多，我只做一些基本的操作。

創(chuàng)建用戶的方式如下，需要做對(duì)比主從checksum的數(shù)據(jù)庫(kù)為backend

GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'pt_checksum'@'10.127.%.%' IDENTIFIED BY 'pt_checksum';

創(chuàng)建的臨時(shí)數(shù)據(jù)庫(kù)為percona，也需要賦予相應(yīng)的權(quán)限。

grant all on percona.* to  'pt_checksum'@'10.127.%.%' ;

checksum的過(guò)程其實(shí)很復(fù)雜，大體有一下的步驟，當(dāng)然我們可以簡(jiǎn)化一下，達(dá)到目標(biāo)然后再深究。

在主庫(kù)端開(kāi)始做checksum,如果碰到下面的錯(cuò)誤。

# 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.

這個(gè)選項(xiàng)的具體含義后續(xù)再琢磨，在row模式下會(huì)有這種警告，可以忽略這項(xiàng)檢查。

[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下會(huì)就生成一個(gè)表，里面的數(shù)據(jù)就是一些對(duì)比的元數(shù)據(jù)，如果存在差別則會(huì)有diffs字段會(huì)有標(biāo)示

如果確認(rèn)無(wú)誤，可以開(kāi)始修復(fù)數(shù)據(jù)，借助pt-table-sync,先把SQL輸出不執(zhí)行，把主庫(kù)和從庫(kù)的信息都正確輸入。

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

而這個(gè)操作的原理其實(shí)就是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*/;

切記要注意權(quán)限，對(duì)于這個(gè)同步數(shù)據(jù)的用戶要開(kāi)通操作目標(biāo)數(shù)據(jù)庫(kù)的權(quán)限。

grant insert,delete,update,select on backend.* to 'pt_checksum'@'10.127.%.%' ;

這個(gè)過(guò)程持續(xù)的時(shí)間不長(zhǎng)，很快就能夠執(zhí)行完畢，修復(fù)之后再次做checksum就完全正常了。

以上就是MySQL主從不一致的修復(fù)過(guò)程是怎樣的，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。