這篇文章主要講解了“MySQL主從不一致的問題分析”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“MySQL主從不一致的問題分析”吧！

創(chuàng)新互聯(lián)是一家專注于網(wǎng)站建設(shè)、網(wǎng)站制作與策劃設(shè)計,玉溪網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)十多年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:玉溪等地區(qū)。玉溪做網(wǎng)站價格咨詢:13518219792

   今天和同事一起看了一個問題，她在一個主從環(huán)境中發(fā)現(xiàn)了數(shù)據(jù)不一致，存在主鍵沖突。

    show slave status的報錯信息大概是下面的樣子。

Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction '0e454161-3169-11e7-98f6-02004d9d000a:665' at master log mysql-bin.000001, end_log_pos 274391. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.      這是一個MySQL 5.7版本的主從環(huán)境，還沒有投入線上業(yè)務(wù)使用，是在搭建的過程中碰到了這類問題。

    一般來說，如果主從數(shù)據(jù)不一致，可以使用pt工具來嘗試檢查和修復(fù)。而這個問題是在搭建主從的時候出現(xiàn)，主從搭建貌似也沒有太多的技巧，開啟GTID，完全夠用了，聽起來確實有些奇怪。

    同事在使用pt工具修復(fù)失敗之后，準(zhǔn)備重建，但是重建的過程也很曲折，slave總是會有主鍵數(shù)據(jù)的沖突。我們檢查了主庫端，數(shù)據(jù)是沒有沖突的，難道這又是bug，我覺得細(xì)細(xì)看看。

     我拿到環(huán)境，準(zhǔn)備向從搭建從庫突破，因為數(shù)據(jù)量不大，所以我重新導(dǎo)入了一次數(shù)據(jù)，是使用最簡單的重定向方式來導(dǎo)入。

# mysql -pxxxxx < db-dump-201705121718.sql
Logging to file '/home/mysql/query.log'
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.  但是我運(yùn)行之后發(fā)現(xiàn)，導(dǎo)入的時候報錯了，在導(dǎo)出的時候其實可以加一個選項，這樣就不會有這類干擾了。

  因為是重新搭建從庫，所以我使用了reset master的方式，

> reset master;
Query OK, 0 rows affected (0.01 sec)  再次導(dǎo)入就沒有問題了。

  接下來就是change master的設(shè)置.

CHANGE MASTER TO       MASTER_HOST='xxxx',        MASTER_USER='rep_user',        MASTER_PASSWORD='xxxx',        MASTER_PORT=3306,        MASTER_AUTO_POSITION = 1;
  啟動slave后發(fā)現(xiàn)同事碰到的錯誤沒有了。

  對于這個問題，我們進(jìn)行了溝通，同事導(dǎo)入的時候使用source的方式導(dǎo)入，說沒有看到錯誤，我們對比了一下搭建方法，也就這個地方不同了。

   帶著試試看的態(tài)度，我使用source的方式搭建了一次。

>source db-dump-201705121718.sql   看到后臺輸出了很多的日志，總體來看是沒有什么異常的地方。然后重啟slave錯誤可以重現(xiàn)了。所以通過這個過程可以基本斷定和bug無關(guān)。

  這個時候我們的關(guān)注點(diǎn)逐步縮小，經(jīng)過論證，就是這個地方的問題，我們來通過幾個小測試來說明。

  我寫了幾行SQL，文件a.sql包含創(chuàng)建表，插入兩行數(shù)據(jù)的操作。

# cat a.sql
create table test(id int);
insert into test values('aaa');
insert into test values(100);使用mysql test < a.sql 還是source的方式都沒有任何報錯。

運(yùn)行后表test的數(shù)據(jù)為:

> select *from test;
+------+
| id   |
+------+
|    0 |
|  100 |
+------+這一點(diǎn)確實讓我有些意外。當(dāng)然問題的重點(diǎn)不在這里，我們繼續(xù)改一下腳本。

# cat a.sql
create table test(id int);
insert into test values('aaa'，'aa');
insert into test values(100);這個時候差別就很明顯了。

# mysql test < a.sql
Logging to file '/home/mysql/query.log'
ERROR 1136 (21S01) at line 2: Column count doesn't match value count at row 1查看數(shù)據(jù)情況，是沒有數(shù)據(jù)插入的。

> select *from test;
Empty set (0.00 sec) 而使用source的方式，日志如下：

> source a.sql
Query OK, 0 rows affected (0.01 sec)
ERROR 1136 (21S01): Column count doesn't match value count at row 1
Query OK, 1 row affected (0.01 sec)查看數(shù)據(jù)，是有1行數(shù)據(jù)的。

所以很大的一個差別就在于此，使用重定向的方式，如果有錯誤會直接退出，而使用source會依次執(zhí)行，錯誤的地方跳過，繼續(xù)執(zhí)行下面的步驟。這樣一個細(xì)小的地方可謂是細(xì)思恐極。對于我們做數(shù)據(jù)變更類的操作而言，是尤其重要的。

感謝各位的閱讀，以上就是“MySQL主從不一致的問題分析”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對MySQL主從不一致的問題分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！