架構(gòu)師必備:MySQL主從同步原理和應(yīng)用
日常工作中,MySQL數(shù)據(jù)庫是必不可少的存儲,其中讀寫分離基本是標配,而這背后需要MySQL開啟主從同步,形成一主一從、或一主多從的架構(gòu),掌握主從同步的原理和知道如何實際應(yīng)用,是一個架構(gòu)師的必備技能。樓主將在本文做總結(jié),看這一篇就夠了。
1、主從同步原理
主從同步架構(gòu)圖(異步同步)
主從同步流程(異步同步)
- 主庫把數(shù)據(jù)變更寫入binlog文件
- 從庫I/O線程發(fā)起dump請求
- 主庫I/O線程推送binlog至從庫
- 從庫I/O線程寫入本地的relay log文件(與binlog格式一樣)
- 從庫SQL線程讀取relay log并重新串行執(zhí)行一遍,得到與主庫相同的數(shù)據(jù)
什么是binlog?
主庫每提交一次事務(wù),都會把數(shù)據(jù)變更,記錄到一個二進制文件中,這個二進制文件就叫binlog。需注意:只有寫操作才會記錄至binlog,只讀操作是不會的(如select、show語句)。
binlog的3種格式:
- statement格式:binlog記錄的是實際執(zhí)行的sql語句
- row格式:binlog記錄的是變化前后的數(shù)據(jù)(涉及所有列),形如update table_a set col1=value1, col2=value2 ... where col1=condition1 and col2=condition2 ...
- mixed格式:默認選擇statement格式,只在需要時改用row格式
binlog格式對比
- statement級別:優(yōu)點是binlog文件小,缺點是主庫的慢sql也會在從庫上再出現(xiàn)一次,一些依賴環(huán)境或上下文的函數(shù)可能會產(chǎn)生不一致的數(shù)據(jù)
- row級別:缺點是文件大(一條語句如果涉及多行,會放大n倍),優(yōu)點是無上述慢sql問題,不依賴環(huán)境或上下文
- 為了獲取前后變化數(shù)據(jù),canal建議使用row級別
主從同步的2種方式
- 異步同步:默認方式,可能會導(dǎo)致主從切換時數(shù)據(jù)丟失。因為主庫是否commit與主從同步流程無關(guān),也不感知。
- 半同步:高可用方案,較新mysql版本支持,需要至少1個從庫(默認1,具體數(shù)量可指定)對寫入relay log進行ack,主庫才會commit并把結(jié)果返回client。
主從同步流程(半同步)
- 從庫在連接主庫時,表明自己支持半同步復(fù)制
- 主庫也需支持半同步復(fù)制,主庫commit事務(wù)前會阻塞等待至少一個從庫寫入relay log的ack,直至超時
- 如果阻塞等待超時,則主庫臨時切換回異步同步模式,當至少一個從庫的半同步追上進度時,主庫再切換至半同步模式
半同步適用場景
高可用備份:半同步復(fù)制,可確保從庫與主庫的一致性,當主庫發(fā)生故障時,切換到從庫不會丟失數(shù)據(jù)。為了保證穩(wěn)定性(不因半同步慢而拖累主庫),一般不承擔業(yè)務(wù)流量、盡可能快地ack,只用于同步備份。
2、主從同步應(yīng)用場景
普通場景:線上從庫異步同步,高可用備份半同步
對一致性要求較高的大數(shù)據(jù)取數(shù)需求
大數(shù)據(jù)取數(shù)可能導(dǎo)致從庫cpu使用率飆升、ack變慢,可設(shè)置半同步所需ack數(shù)量為1,正常情況下高可用備份能很快ack,于是主庫會commit并返回,而大數(shù)據(jù)取數(shù)復(fù)制慢一些也無所謂。這樣就不會因為大數(shù)據(jù)取數(shù)ack慢而影響主庫和業(yè)務(wù)了。
參考:mysql官方文檔
- https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html
- https://dev.mysql.com/doc/internals/en/binary-log-overview.html