在使用Mysql的主從復(fù)制架構(gòu)中，有兩個比較頭疼的問題：

1、主從數(shù)據(jù)不同步后如何處理

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

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

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

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

出現(xiàn)第一種情況通常原因是手工去修改了從庫的數(shù)據(jù)導(dǎo)致主從數(shù)據(jù)不一致，這種情況如果不及時處理，當(dāng)主庫也更新了對應(yīng)的數(shù)據(jù)的時候，就會演變?yōu)榈诙N情況。

舉個例子：

在一主一從的條件下，當(dāng)前主從的數(shù)據(jù)是同步的。

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

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

當(dāng)主庫的這條數(shù)據(jù)未變動的時候，當(dāng)前主從同步進(jìn)程中Slave_IO_Running和Slave_SQL_Running還是為YES，目前只是asm_user這張表的數(shù)據(jù)不同步而已，對應(yīng)其他schema上的數(shù)據(jù)還是會保持主從同步；

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

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

對應(yīng)的SQL apply到從庫的時候就會發(fā)現(xiàn)duplicate key,這個時候主從的同步就會停止掉。

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

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

這個辦法其實(shí)回答了前面的問題1，Slave_IO_Running和Slave_SQL_Running在YES情況下，主從數(shù)據(jù)不同步如何處理？#?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

如果主從數(shù)據(jù)不一致則采用mk-table-sync進(jìn)行數(shù)據(jù)同步#?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

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

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

在未啟用GTID復(fù)制的情況下采用下面的方法跳過事務(wù)：mysql>slave?stop;

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

mysql>slave?start;

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

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

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

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

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

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

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

mysql>?begin;commit;

mysql>?set?session?gtid_next=automatic;

mysql>?start?slave;

mysql>?show?slave?status?\G;

驗證從庫數(shù)據(jù)是否和主庫一致

mysql> select * from test.asm_user;

前面模擬了Slave_SQL_Running在NO情況下，主從數(shù)據(jù)不同步情況的處理過程，在現(xiàn)實(shí)的環(huán)境中，往往情況要復(fù)雜的多，下面分享一則內(nèi)存開發(fā)庫因為斷電導(dǎo)致主從數(shù)據(jù)不一致的故障處理：

1、因為電源故障，導(dǎo)致主從數(shù)據(jù)庫全部宕機(jī)，電源恢復(fù)后，主庫啟動正常，從庫無法啟動，通過分析日志發(fā)現(xiàn)可能是電源故障導(dǎo)致從庫的固態(tài)盤異常，許多的binlog文件權(quán)限出現(xiàn)？？？，這些文件甚至無法正常查看

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

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

下面是大致的步驟：

3.1、主庫導(dǎo)出全庫數(shù)據(jù)，注意一定要使用--single-transaction參數(shù)

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

3.2、將備份文件拷貝到從庫進(jìn)行source

3.3、開啟從庫的復(fù)制進(jìn)程

mysql>change?master?to?master_host='192.168.1.15',

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

mysql>start slave;

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。