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