MySQL主從不一致的問(wèn)題分析

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

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

    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.      這是一個(gè)MySQL 5.7版本的主從環(huán)境，還沒(méi)有投入線(xiàn)上業(yè)務(wù)使用，是在搭建的過(guò)程中碰到了這類(lèi)問(wèn)題。

    一般來(lái)說(shuō)，如果主從數據不一致，可以使用pt工具來(lái)嘗試檢查和修復。而這個(gè)問(wèn)題是在搭建主從的時(shí)候出現，主從搭建貌似也沒(méi)有太多的技巧，開(kāi)啟GTID，完全夠用了，聽(tīng)起來(lái)確實(shí)有些奇怪。

    同事在使用pt工具修復失敗之后，準備重建，但是重建的過(guò)程也很曲折，slave總是會(huì )有主鍵數據的沖突。我們檢查了主庫端，數據是沒(méi)有沖突的，難道這又是bug，我覺(jué)得細細看看。

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

# 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.  但是我運行之后發(fā)現，導入的時(shí)候報錯了，在導出的時(shí)候其實(shí)可以加一個(gè)選項，這樣就不會(huì )有這類(lèi)干擾了。

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

> reset master;
Query OK, 0 rows affected (0.01 sec)  再次導入就沒(méi)有問(wèn)題了。

  接下來(lái)就是change master的設置.

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

  對于這個(gè)問(wèn)題，我們進(jìn)行了溝通，同事導入的時(shí)候使用source的方式導入，說(shuō)沒(méi)有看到錯誤，我們對比了一下搭建方法，也就這個(gè)地方不同了。

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

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

  這個(gè)時(shí)候我們的關(guān)注點(diǎn)逐步縮小，經(jīng)過(guò)論證，就是這個(gè)地方的問(wèn)題，我們來(lái)通過(guò)幾個(gè)小測試來(lái)說(shuō)明。

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

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

運行后表test的數據為:

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

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

# 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查看數據情況，是沒(méi)有數據插入的。

> 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)查看數據，是有1行數據的。

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