資訊專欄INFORMATION COLUMN
MySQL主從復制技術應用非常廣泛，M-S復制架構、keepalived＋M-M復制架構、MHA等高可用架構都基于MySQL主從復制技術。但因主從復制是基于binlog的邏輯復制，實際應中,可能會因為各種原因出現主從數據不一致的情況,關系數據則無小事,因此我們需要定期或不定期地開展主從復制數據一致性的校驗和修復工作。那么對于mysql主從數據不一致的情況,應該怎樣修復呢?不止一次聽到說只需要從主庫重新導入備庫就可以了,咋一聽似乎沒毛病,但細思極恐,下面我們來探討這些問題。
Master節點
mysqldump -uxxx -p test aa--set-gtid-purged=OFF > aa.sql
Slave節點
Source aa.sql
Start slave;
很多人處理數據不一致時采用以上操作,甚至有些專業MySQLDBA也是采取如此操作,如果數據完全靜態,這樣操作沒有問題。但數據往往都是動態變化的,那如何確保導出導入和salve故障點的時刻的一致性呢?“現在mysql都是基于GTID的復制,mysql自己會找去從哪里開始復制”有人這樣解釋,但是GTID是全局的,在運行的復制架構中,無法自動針對某一張表去挑選數據進行復制應用。
下面就上面的操作進行詳細分析,以下數據表特指復制中存在數據差異的數據表：
T1時刻發現復制異常
T2時刻在master導出數據表
T3時刻在slave導入數據表并啟動復制
T1時刻之前就已經發生了錯誤,復制異常時binglog日志中記錄的錯誤時間點早于T1時刻,slave導入數據之后,日志開始應用的位置是早于T1而不是從T2開始,那么salve節點將會重復故障點到T2時刻的操作,結果大概率是報錯,或者是主從數據仍然不一致。
那么可以臨時跳過出錯的表(REPLICATE_WILD_IGNORE_TABLE),主從復制無延遲的時候再進行修復導出導入的修復操作,還是以上面的圖為例:
假定數據是持續變化的,修復過程中salve不停止應用日志,且復制基本無延遲：
T1時刻在master導出數據表
T2時刻在slave導入數據表,并取消REPLICATE_WILD_IGNORE_TABLE設置,重啟slave復制
那么slave節點將缺少T1至T2時刻的數據表的數據變更,結果要么無法啟動復制要么數據存在不一致,存在后續復制異常的隱患。
既然導數過程種slave復制正常運行會導致異常,那停止slave復制后再修復是怎樣的呢,下面來看一下:
T1時刻在slave停止復制
T2時刻在master導出數據表
T3時刻在slave導入數據表,并取消REPLICATE_WILD_IGNORE_TABLE設置,重啟slave復制
那么slave節點將重復T1至T2時刻的數據表的數據變更,結果要么無法啟動復制要么數據存在不一致,存在后續復制異常的隱患。
既然無論slave是保持復制還是停止復制,數據都不對,那正確操作是怎樣的?
既然無論slave是保持復制還是停止復制,數據都不對,那正確操作是怎樣的?假如salve節點在a時刻停止復制,master在b時刻導出數據,如a時刻salve節點應用binlog的位置和b時刻Masterbinlog位置相同即可確保數據一致,該操作幾乎無法人為確保,但是我們可以確a和b之間數據表沒有數據變更,下面描述具體過程:
T1:設置數據表只讀
lock tables aa read;
T2:停止slave復制(復制無延遲的情況下,確保停止時間點在T1之后)
T3:一致性導出數據表
mysqldump -uroot test aa--set-gtid-purged=OFF --single-transaction > aa.sql
導出后可解鎖master上的鎖定,減少業務影響時間,如執行如上語句做一致性快照導出,導出開始后即可解鎖master,無需等待導出結束
T4:在slave導入數據表,并取消REPLICATE_WILD_IGNORE_TABLE設置,重啟slave復制
因為T1至T3時刻數據表沒有數據變更,salve復制停止在T1與T3之間,故master和slave數據是一致的,T4時刻開啟復制應用,salve從T2時刻的日志開始應用,數據一致,不會發生異常。
除了以上方式將數據修復一致之外,還可以使用pt-table-sync,以及傳輸表空間的方式進行數據修復,甚至手工處理差異的數據,視具體場景(差異量,影響范圍,修復所需時間及影響)選擇合適的修復方式。
相比修復問題,日常預防問題發生更加重要,異常宕機以及人為操作常常導致數據差異。
異常宕機：可通過更安全的配置選項規避,但安全性和性能往往不能兼得,需要結合具體業務評估。
人為操作：我遇到的數據不一致大部分為非運維人員不恰當的操作導致數據差異,設置salve節點只讀可有效避免。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/130140.html
摘要：簡介項目地址主從環境下數據一致性校驗經常會用工具，它的原理及實施過程之前寫過一篇文章生產環境使用檢查數據一致性。上面的配置文件可以認為是用于控制程序的，這個配置文件是指定要校驗的源庫和目標庫信息，以及要檢驗哪些表。 1. 簡介 項目地址：https://github.com/seanlook/p... 主從環境下數據一致性校驗經常會用 pt-table-checksum 工具，它的原理...
摘要：通過對一些客戶的跨云遷移過程進行總結，發現普遍存在的挑戰有三點數據完整性和一致性挑戰。簡而言之，跨云遷移過程中的數據一致性主要就集中在存量數據的遷移如何保證一致。前言隨著互聯網業務發展對容災以及對訪問加速、多供應商成本控制等需求的產生，互聯網公司的多云部署和跨云遷移逐漸成為剛需，而在此過程中，最困擾運維和研發人員的就是數據的遷移和同步。俗語說 上屋搬下屋，搬灑一籮谷 ，在業務的遷移過程中一旦...
摘要：的主從備份相關配置服務器號，不要和其他服務器重復開啟二進制日志索引二進制日志的文件名設為就是把每次發生的修改和事件的日志即時同步到硬盤上復制模式防止從服務器在崩潰后自動開啟，以給你足夠的時間修復。 實踐背景 最近加入了同學的技術分享小組，4個人分兩組，半月進行一次技術分享，現在一起搞Mysql我被分到講解Mysql日志方面，上周已經講完了，不過他們總是覺得對于日志這塊了解不透徹，覺得不...
閱讀 1353·2023-01-11 13:20
閱讀 1699·2023-01-11 13:20
閱讀 1211·2023-01-11 13:20
閱讀 1902·2023-01-11 13:20
閱讀 4161·2023-01-11 13:20
閱讀 2748·2023-01-11 13:20
閱讀 1397·2023-01-11 13:20
閱讀 3664·2023-01-11 13:20
