MySQL主從不一致的問題分析

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

   今天和同事一起看了一個問題，她在一個主從環境中發現了數據不一致，存在主鍵沖突。

    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版本的主從環境，還沒有投入線上業務使用，是在搭建的過程中碰到了這類問題。

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

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

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

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

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

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

  接下來就是change master的設置.

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

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

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

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

  這個時候我們的關注點逐步縮小，經過論證，就是這個地方的問題，我們來通過幾個小測試來說明。

  我寫了幾行SQL，文件a.sql包含創建表，插入兩行數據的操作。

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

運行后表test的數據為:

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

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

> 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行數據的。

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

感謝各位的閱讀，以上就是“MySQL主從不一致的問題分析”的內容了，經過本文的學習后，相信大家對MySQL主從不一致的問題分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！