1、主從同步原理

主從同步架構(gòu)圖（異步同步）

這是最常見的主從同步架構(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，直至超時
• 如果阻塞等待超時，則主庫臨時切換回異步同步模式，當(dāng)至少一個從庫的半同步追上進度時，主庫再切換至半同步模式

半同步適用場景

高可用備份：半同步復(fù)制，可確保從庫與主庫的一致性，當(dāng)主庫發(fā)生故障時，切換到從庫不會丟失數(shù)據(jù)。為了保證穩(wěn)定性（不因半同步慢而拖累主庫），一般不承擔(dā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ù)了。

到此這篇關(guān)于MySQL主從同步原理及應(yīng)用的文章就介紹到這了,更多相關(guān)MySQL主從同步原理及應(yīng)用內(nèi)容請搜索本站以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持本站！

美國服務(wù)器租用

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。