MySQL主從復(fù)制技術(shù)應(yīng)用非常廣泛，M-S復(fù)制架構(gòu)、keepalived＋M-M復(fù)制架構(gòu)、MHA等高可用架構(gòu)都基于MySQL主從復(fù)制技術(shù)。但因主從復(fù)制是基于binlog的邏輯復(fù)制，實(shí)際應(yīng)中,可能會(huì)因?yàn)楦鞣N原因出現(xiàn)主從數(shù)據(jù)不一致的情況,關(guān)系數(shù)據(jù)則無(wú)小事,因此我們需要定期或不定期地開(kāi)展主從復(fù)制數(shù)據(jù)一致性的校驗(yàn)和修復(fù)工作。那么對(duì)于mysql主從數(shù)據(jù)不一致的情況,應(yīng)該怎樣修復(fù)呢?不止一次聽(tīng)到說(shuō)只需要從主庫(kù)重新導(dǎo)入備庫(kù)就可以了,咋一聽(tīng)似乎沒(méi)毛病,但細(xì)思極恐,下面我們來(lái)探討這些問(wèn)題。

Master節(jié)點(diǎn)

mysqldump -uxxx -p  test aa--set-gtid-purged=OFF  > aa.sql

Slave節(jié)點(diǎn)

Source aa.sql

Start slave;

很多人處理數(shù)據(jù)不一致時(shí)采用以上操作,甚至有些專(zhuān)業(yè)MySQLDBA也是采取如此操作,如果數(shù)據(jù)完全靜態(tài),這樣操作沒(méi)有問(wèn)題。但數(shù)據(jù)往往都是動(dòng)態(tài)變化的,那如何確保導(dǎo)出導(dǎo)入和salve故障點(diǎn)的時(shí)刻的一致性呢?“現(xiàn)在mysql都是基于GTID的復(fù)制,mysql自己會(huì)找去從哪里開(kāi)始復(fù)制”有人這樣解釋,但是GTID是全局的,在運(yùn)行的復(fù)制架構(gòu)中,無(wú)法自動(dòng)針對(duì)某一張表去挑選數(shù)據(jù)進(jìn)行復(fù)制應(yīng)用。

下面就上面的操作進(jìn)行詳細(xì)分析,以下數(shù)據(jù)表特指復(fù)制中存在數(shù)據(jù)差異的數(shù)據(jù)表：

• T1時(shí)刻發(fā)現(xiàn)復(fù)制異常

• T2時(shí)刻在master導(dǎo)出數(shù)據(jù)表

• T3時(shí)刻在slave導(dǎo)入數(shù)據(jù)表并啟動(dòng)復(fù)制

T1時(shí)刻之前就已經(jīng)發(fā)生了錯(cuò)誤,復(fù)制異常時(shí)binglog日志中記錄的錯(cuò)誤時(shí)間點(diǎn)早于T1時(shí)刻,slave導(dǎo)入數(shù)據(jù)之后,日志開(kāi)始應(yīng)用的位置是早于T1而不是從T2開(kāi)始,那么salve節(jié)點(diǎn)將會(huì)重復(fù)故障點(diǎn)到T2時(shí)刻的操作,結(jié)果大概率是報(bào)錯(cuò),或者是主從數(shù)據(jù)仍然不一致。

那么可以臨時(shí)跳過(guò)出錯(cuò)的表(REPLICATE_WILD_IGNORE_TABLE),主從復(fù)制無(wú)延遲的時(shí)候再進(jìn)行修復(fù)導(dǎo)出導(dǎo)入的修復(fù)操作,還是以上面的圖為例:

假定數(shù)據(jù)是持續(xù)變化的,修復(fù)過(guò)程中salve不停止應(yīng)用日志,且復(fù)制基本無(wú)延遲：

• T1時(shí)刻在master導(dǎo)出數(shù)據(jù)表

• T2時(shí)刻在slave導(dǎo)入數(shù)據(jù)表,并取消REPLICATE_WILD_IGNORE_TABLE設(shè)置,重啟slave復(fù)制

那么slave節(jié)點(diǎn)將缺少T1至T2時(shí)刻的數(shù)據(jù)表的數(shù)據(jù)變更,結(jié)果要么無(wú)法啟動(dòng)復(fù)制要么數(shù)據(jù)存在不一致,存在后續(xù)復(fù)制異常的隱患。

既然導(dǎo)數(shù)過(guò)程種slave復(fù)制正常運(yùn)行會(huì)導(dǎo)致異常,那停止slave復(fù)制后再修復(fù)是怎樣的呢,下面來(lái)看一下:

• T1時(shí)刻在slave停止復(fù)制

• T2時(shí)刻在master導(dǎo)出數(shù)據(jù)表

• T3時(shí)刻在slave導(dǎo)入數(shù)據(jù)表,并取消REPLICATE_WILD_IGNORE_TABLE設(shè)置,重啟slave復(fù)制

那么slave節(jié)點(diǎn)將重復(fù)T1至T2時(shí)刻的數(shù)據(jù)表的數(shù)據(jù)變更,結(jié)果要么無(wú)法啟動(dòng)復(fù)制要么數(shù)據(jù)存在不一致,存在后續(xù)復(fù)制異常的隱患。

既然無(wú)論slave是保持復(fù)制還是停止復(fù)制,數(shù)據(jù)都不對(duì),那正確操作是怎樣的?

既然無(wú)論slave是保持復(fù)制還是停止復(fù)制,數(shù)據(jù)都不對(duì),那正確操作是怎樣的?假如salve節(jié)點(diǎn)在a時(shí)刻停止復(fù)制,master在b時(shí)刻導(dǎo)出數(shù)據(jù),如a時(shí)刻salve節(jié)點(diǎn)應(yīng)用binlog的位置和b時(shí)刻Masterbinlog位置相同即可確保數(shù)據(jù)一致,該操作幾乎無(wú)法人為確保,但是我們可以確a和b之間數(shù)據(jù)表沒(méi)有數(shù)據(jù)變更,下面描述具體過(guò)程:

• T1:設(shè)置數(shù)據(jù)表只讀

lock tables aa read;

• T2:停止slave復(fù)制(復(fù)制無(wú)延遲的情況下,確保停止時(shí)間點(diǎn)在T1之后)

  
  

• T3:一致性導(dǎo)出數(shù)據(jù)表

mysqldump -uroot test aa--set-gtid-purged=OFF --single-transaction > aa.sql

導(dǎo)出后可解鎖master上的鎖定,減少業(yè)務(wù)影響時(shí)間,如執(zhí)行如上語(yǔ)句做一致性快照導(dǎo)出,導(dǎo)出開(kāi)始后即可解鎖master,無(wú)需等待導(dǎo)出結(jié)束

• T4:在slave導(dǎo)入數(shù)據(jù)表,并取消REPLICATE_WILD_IGNORE_TABLE設(shè)置,重啟slave復(fù)制

因?yàn)門(mén)1至T3時(shí)刻數(shù)據(jù)表沒(méi)有數(shù)據(jù)變更,salve復(fù)制停止在T1與T3之間,故master和slave數(shù)據(jù)是一致的,T4時(shí)刻開(kāi)啟復(fù)制應(yīng)用,salve從T2時(shí)刻的日志開(kāi)始應(yīng)用,數(shù)據(jù)一致,不會(huì)發(fā)生異常。

除了以上方式將數(shù)據(jù)修復(fù)一致之外,還可以使用pt-table-sync,以及傳輸表空間的方式進(jìn)行數(shù)據(jù)修復(fù),甚至手工處理差異的數(shù)據(jù),視具體場(chǎng)景(差異量,影響范圍,修復(fù)所需時(shí)間及影響)選擇合適的修復(fù)方式。

相比修復(fù)問(wèn)題,日常預(yù)防問(wèn)題發(fā)生更加重要,異常宕機(jī)以及人為操作常常導(dǎo)致數(shù)據(jù)差異。

異常宕機(jī)：可通過(guò)更安全的配置選項(xiàng)規(guī)避,但安全性和性能往往不能兼得,需要結(jié)合具體業(yè)務(wù)評(píng)估。

人為操作：我遇到的數(shù)據(jù)不一致大部分為非運(yùn)維人員不恰當(dāng)?shù)牟僮鲗?dǎo)致數(shù)據(jù)差異,設(shè)置salve節(jié)點(diǎn)只讀可有效避免。