在使用Mysql的主從復制架構中，有兩個比較頭疼的問題：

1、主從數據不同步后如何處理

2、主從同步延遲問題如何解決

本文將根據實際案例來分析下問題1，至于問題2多數文檔介紹的辦法是啟用多線程復制來解決，言歸正傳，這里的問題1還可以細分成兩種情況。

1、Slave_IO_Running和Slave_SQL_Running在YES情況下，主從數據不同步如何處理？

2、Slave_SQL_Running在NO情況下，主從數據不同步如何處理？

出現第一種情況通常原因是手工去修改了從庫的數據導致主從數據不一致，這種情況如果不及時處理，當主庫也更新了對應的數據的時候，就會演變為第二種情況。

舉個例子：

在一主一從的條件下，當前主從的數據是同步的。

wKioL1defkyRX4N5AAAsgdsSjK0970.png-wh_50

人為去操作從庫的某張表數據,本例中以asm_user表為演示，其中id字段為主鍵

mysql> insert into test.asm_user (id,name,salary) values (1,'a',10000);

wKioL1defnOQRVV1AAAbXUTtCaw457.png-wh_50

當主庫的這條數據未變動的時候，當前主從同步進程中Slave_IO_Running和Slave_SQL_Running還是為YES，目前只是asm_user這張表的數據不同步而已，對應其他schema上的數據還是會保持主從同步；

但如果這個情況，主庫執行相同的SQL語句：

mysql> insert into test.asm_user (id,name,salary) values (1,'a',10000);

wKiom1defYWD6mNsAAAulN7mfCk568.png-wh_50

對應的SQL apply到從庫的時候就會發現duplicate key,這個時候主從的同步就會停止掉。

wKioL1deg_aB1GSFAADVt0D2mrI706.jpg-wh_50

# tail -f /home/mydata/localhost.localdomain.err

wKiom1degxHSg_fYAAHU5lGGFJE782.jpg-wh_50

這種情況下，一般我們采用maatkit工具來校驗主從數據庫的數據差異情況。

這個辦法其實回答了前面的問題1，Slave_IO_Running和Slave_SQL_Running在YES情況下，主從數據不同步如何處理？

# yum -y install perl-TermReadKey

# wget ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/maatkit-7540.tar.gz

# tar -zxvpf maatkit-7540.tar.gz

# cd maatkit-7540

# perl Makefile.PL

# make && make install

# mk-table-checksum h=192.168.115.6,u=root,p=123456,P=3306 ?\

h=192.168.115.7,u=root,p=123456,P=3306 -d test | mk-checksum-filter

# mk-table-checksum h=192.168.115.6,u=root,p=123456,P=3306 \

h=192.168.115.7,u=root,p=123456,P=3306 -d test

wKioL1defwTiewiDAAAf3dxeEvM458.png-wh_50

如果主從數據不一致則采用mk-table-sync進行數據同步

# mk-table-sync --execute --print --no-check-slave --transaction --databases test ?\

h=192.168.115.6,u=root,p=123456 h=192.168.115.7,u=root,p=123456

很明顯當前test庫數據是一致的，目前主從同步這個錯誤是可以忽略的，因此我們采用跳過這個事務的辦法來處理主從數據庫不同步問題。通常在生產環境中，主庫的數據是不斷的更新的，這里我們在主從數據不同步的情況下在主庫繼續插入一條數據，方便后續驗證。

wKiom1defiiSepqiAAAHhCqI68I693.png-wh_50

下面我們開始處理主從不同步問題：

在未啟用GTID復制的情況下采用下面的方法跳過事務：

mysql>slave stop;

mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; ?//跳過一個事務

mysql>slave start;

Mysql5.6之后支持GTID復制，開啟GTID復制的好處很多，具體可以百度一下！但當開啟gtid后就不能采用前面那種辦法來跳過事務。

wKiom1defmHANpENAAAbbunNJGg135.png-wh_50

在show slave status \G;輸出中的最后幾條里面，

Retrieved_Gtid_Set項：記錄了relay日志從Master獲取了binlog日志的位置

Executed_Gtid_Set項：記錄本機執行的binlog日志位置(如果是從機，包括Master的binlog日志位置和slave本身的binlog日志位置)

wKiom1defnejlgvOAABIDzTvZPo455.png-wh_50

我們要跳過事務的GTID在錯誤日志中有記錄

# tail -f /home/mydata/localhost.localdomain.err

wKiom1defp6BFAf4AABxhFEkNRE916.png-wh_50

mysql> set session gtid_next='bd9e9912-2bc7-11e6-bade-000c29b8871c:1440';

mysql> begin;commit;

mysql> set session gtid_next=automatic;

wKiom1defruipUhkAAAWDyHizeU551.png-wh_50

mysql> start slave;

mysql> show slave status \G;

wKiom1deftez44ZfAAAxVx15lp4238.png-wh_50

驗證從庫數據是否和主庫一致

mysql> select * from test.asm_user;

wKioL1degAejA92LAAAJkqFK890385.png-wh_50

前面模擬了Slave_SQL_Running在NO情況下，主從數據不同步情況的處理過程，在現實的環境中，往往情況要復雜的多，下面分享一則內存開發庫因為斷電導致主從數據不一致的故障處理：

1、因為電源故障，導致主從數據庫全部宕機，電源恢復后，主庫啟動正常，從庫無法啟動，通過分析日志發現可能是電源故障導致從庫的固態盤異常，許多的binlog文件權限出現？？？，這些文件甚至無法正常查看

wKioL1degB-A0o4tAAIJHQ0T6_o437.png-wh_50

1、通過fsck -y進行文件系統校驗修復壞塊，修復完成后從庫數據庫可以啟動，但開啟復制進程的時候報中繼日志丟失

2、在沒有辦法的情況下，采用主庫dump數據，從庫重新source的辦法在線重做主從數據同步。整個操作過程中，主庫的數據不斷的寫入。

下面是大致的步驟：

3.1、主庫導出全庫數據，注意一定要使用--single-transaction參數

# /usr/local/mysql/bin/mysqldump --all-databases --single-transaction --triggers --routines > /tmp/1.sql

3.2、將備份文件拷貝到從庫進行source

3.3、開啟從庫的復制進程

mysql> change master to master_host='192.168.1.15',

master_user='rep1',master_password='123456',MASTER_AUTO_POSITION=1;

mysql> start slave;

?著作權歸作者所有：來自51CTO博客作者ylw6006的原創作品，謝絕轉載，否則將追究法律責任

mysqlmasterslaveMysql

總結

以上是生活随笔為你收集整理的mysql主从不同步 tar_Mysql主从不同步问题处理案例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。