MySQL集群數(shù)據(jù)問題修復(fù)小記 這是學(xué)習(xí)筆記的第 2249 篇文章 讀完需要9分鐘 速讀僅需7分鐘 最近有一套集群有數(shù)據(jù)不一致的報警，最開始沒有引起注意，整體的拓?fù)浣Y(jié)構(gòu)如下，這是一個偏日志型寫入業(yè)務(wù)，上層是使用中間件來做分庫分表，數(shù)據(jù)分片層做了跨機房容災(zāi)，一主兩從，而且基于Consul域名管理，也算是跨機房高可用。 因為近期需要把這一套集群跨機房遷移到新機房，整體的方案和設(shè)計都算是高大上的，根據(jù)之前的切換都是秒級（2-3秒左右）閃斷完成，業(yè)務(wù)初期是不需要做任何調(diào)整的，整體來說對業(yè)務(wù)是平滑無感知的。 在遷移前在處理主從數(shù)據(jù)不一致的情況時，發(fā)現(xiàn)問題有些蹊蹺，總是有個別的數(shù)據(jù)在從庫會出現(xiàn)自增列沖突的情況，設(shè)置了從庫slave_exec_mode為idempotent冪等后，能夠臨時解決問題，但是總歸是不嚴(yán)謹(jǐn)?shù)模院蛨F隊討論了一番，決定重構(gòu)從庫。 我們認(rèn)為當(dāng)前的拓?fù)浼軜?gòu)是這樣的，打算是基于物理備份的模式來做。 沒想到這個過程中因為數(shù)據(jù)量較大，備份中基于虛擬環(huán)境，IO負(fù)載很高，導(dǎo)致MHA的ping insert檢查超時失敗，所以我們看到的一個數(shù)據(jù)分片的拓?fù)浣Y(jié)構(gòu)是這樣的。（MHA目前不允許跨機房自動切換）。 碰到這個問題，著實讓我有些抓狂，而因為Consul健康檢查不嚴(yán)謹(jǐn)?shù)脑颍幸徊糠值臄?shù)據(jù)其實是寫入到原來的兩個Master上面了。這種混寫持續(xù)了一段時間，而雪上加霜的時，這個過程的報警有不好使了，確實比較尷尬，所以我們需要立刻采取有效措施來修復(fù)數(shù)據(jù)。 分析了整體的數(shù)據(jù)情況，如果保留已有的拓?fù)浣Y(jié)構(gòu)，建立反向復(fù)制關(guān)系，應(yīng)該是比較合理的，但是New Master到Old Master的反向復(fù)制關(guān)系建立失敗（因為binlog保留時間短，有缺失，雪上加霜2.0），我們決定先把數(shù)據(jù)源切換到原主庫Old Master，這個時候新主庫上面的數(shù)據(jù)勢必會比主庫上要多,但是我們在這個時候還有一些緩和的余地。 這個時候搭建從庫的過程是很關(guān)鍵的，因為整個環(huán)境沒有一個基準(zhǔn)了，需要快速修復(fù)，我們開始基于時間范圍做兩端數(shù)據(jù)的比對工作，整個工作比想象的扼要快一些。 大體的思路就是在新機房搭建一個新的中間件，配置兩套schema環(huán)境，這樣就可以比對兩個數(shù)據(jù)庫中的數(shù)據(jù)情況了，我從數(shù)據(jù)量小的一些表開始逐步排查，經(jīng)過一些比對，排除了這個過程中數(shù)據(jù)混寫的狀態(tài)。 數(shù)據(jù)狀態(tài)整體是這樣的：old masternew master1122334455667788 9 10 11151516161717 所以在確認(rèn)之后，我們開始快速搭建從庫，停止了MHA之后，我們直接停止了New Master實例,，然后直接拷貝整個數(shù)據(jù)目錄到跨機房的環(huán)境中，這種方式簡單粗暴，但是確實有效。有的朋友肯定會說這個過程不嚴(yán)謹(jǐn)，一定會丟數(shù)據(jù)，確實是，但是我們打算很快把數(shù)據(jù)源切回來。 因為數(shù)據(jù)比對的過程是比較敏感的，基本都是全表掃描，而且在當(dāng)時的情況下，能夠完成數(shù)據(jù)比對我們才能夠真正放心數(shù)據(jù)不是我們理解中的“隨機寫”，所以這個過程是確保要做驗證的，驗證完后有細微的數(shù)據(jù)修復(fù)，可以直接修復(fù)，整體還是可控的。所以在完成從庫之后，我們把數(shù)據(jù)源切回了New Master,畢竟這是經(jīng)過稽核確認(rèn)的一個準(zhǔn)確的數(shù)據(jù)源。 在這個基礎(chǔ)上，我們繼續(xù)完成第二階段的從庫部署，即把跨機房的從庫停掉，然后直接復(fù)制文件到原來Old Master中，整個過程對于業(yè)務(wù)都是影響最低的。 當(dāng)然在這個過程中著實發(fā)現(xiàn)了很多低級錯誤，我們需要對整個問題復(fù)盤，繼續(xù)修正。 我在做運維操作的時候，經(jīng)常給同事提到兩件事情： 1）怎么證明你的操作是正確的 2）怎么保證你的操作是可控的 如果能夠做到以上兩點，別人也基本挑不出一些硬性問題。 QQ群號：763628645 QQ群二維碼如下， 添加請注明：姓名+地區(qū)+職位，否則不予通過 7 近期熱文 你可能也會對以下話題感興趣。點擊鏈接就可以查看。 如何優(yōu)化MySQL千萬級大表，我寫了6000字的解讀 小白學(xué)MySQL要多久?我整理了10多個問題的答案 說說我的新書《MySQL DBA工作筆記》 《鳳凰項目》讀書筆記（一） 使用Python分析北京積分落戶數(shù)據(jù)，分析完我陷入了深思 MySQL的主鍵命名挺任性，就這么定了 華裔教授發(fā)現(xiàn)二次方程極簡解法,我默默的做了下驗算 回答:我不小心把公司的數(shù)據(jù)庫給刪了，該不該離職？ 遷移到MySQL的業(yè)務(wù)架構(gòu)演進實戰(zhàn) 數(shù)據(jù)庫修改密碼風(fēng)險高，如何保證業(yè)務(wù)持續(xù)，這幾種密碼雙活方案可以參考 MySQL業(yè)務(wù)雙活的初步設(shè)計方案 一道經(jīng)典的MySQL面試題，答案出現(xiàn)三次反轉(zhuǎn) 業(yè)務(wù)雙活的數(shù)據(jù)切換思路設(shè)計（下） 業(yè)務(wù)雙活的數(shù)據(jù)切換思路設(shè)計（一） MySQL中的主鍵和rowid,看似簡單,其實有一些使用陷阱需要注意