快捷導(dǎo)航

一文詳解MySQL主從同步原理

更新時(shí)間：2022年08月16日 10:41:34 作者：一燈架構(gòu)???????

這篇文章主要介紹了一文詳解MySQL主從同步原理，MySQL主從同步是基于Bin?Log實(shí)現(xiàn)的，而B(niǎo)in?Log記錄的是原始SQL語(yǔ)句，更多相關(guān)內(nèi)容介紹感興趣的小伙伴可以參考一下

1. MySQL主從同步實(shí)現(xiàn)方式

MySQL主從同步是基于Bin Log實(shí)現(xiàn)的，而B(niǎo)in Log記錄的是原始SQL語(yǔ)句。

Bin Log共有三種日志格式，可以binlog_format配置參數(shù)指定。

參數(shù)值	含義
Statement	記錄原始SQL語(yǔ)句，會(huì)導(dǎo)致更新時(shí)間與原庫(kù)不一致。比如 update_time=now()
Row	記錄每行數(shù)據(jù)的變化，保證了數(shù)據(jù)與原庫(kù)一致，缺點(diǎn)是數(shù)據(jù)量較大。
Mixed	Statement和Row的混合模式，默認(rèn)采用Statement模式，涉及日期、函數(shù)相關(guān)的時(shí)候采用Row模式，既減少了數(shù)據(jù)量，又保證了數(shù)據(jù)一致性。

常見(jiàn)的主從同步架構(gòu)有一主多從、雙主多從

2. MySQL主從同步的作用

讀寫(xiě)分離，提升數(shù)據(jù)庫(kù)性能
容災(zāi)恢復(fù)，主服務(wù)器不可用時(shí)，從服務(wù)器提供服務(wù)，提高可用性
冗余備份，主服務(wù)器數(shù)據(jù)損壞丟失，從服務(wù)器保留備份

一主多從架構(gòu)

一般是主庫(kù)負(fù)責(zé)所有讀寫(xiě)請(qǐng)求，而從庫(kù)只負(fù)責(zé)容災(zāi)恢復(fù)和冗余備份。

如果做了讀寫(xiě)分離的話，主庫(kù)負(fù)責(zé)寫(xiě)請(qǐng)求，從庫(kù)負(fù)責(zé)讀請(qǐng)求，可以提升數(shù)據(jù)庫(kù)性能。

雙主多從架構(gòu)

一般是主庫(kù)1負(fù)責(zé)所有讀寫(xiě)請(qǐng)求，主庫(kù)2不對(duì)外提供服務(wù)，只用來(lái)容災(zāi)恢復(fù)。

相比一主多從架構(gòu)，雙主多從架構(gòu)可以減少宕機(jī)時(shí)間，更快恢復(fù)數(shù)據(jù)庫(kù)可用狀態(tài)。

3. 主動(dòng)同步的原理

當(dāng)主庫(kù)數(shù)據(jù)發(fā)生變更時(shí)，寫(xiě)入本地Bin Log文件
從庫(kù)IO線程發(fā)起dump主庫(kù)Bin Log文件的請(qǐng)求
主庫(kù)IO線程推送Bin Log文件到從庫(kù)中
從庫(kù)IO線程把Bin Log內(nèi)容寫(xiě)入本地的Relay Log文件中
從庫(kù)SQL線程讀取Relay Log文件內(nèi)容
從庫(kù)SQL線程重新執(zhí)行一遍SQL語(yǔ)句

4. 主從同步延遲問(wèn)題

主從同步最常遇到的問(wèn)題就是主從同步延遲，可以通過(guò)在從庫(kù)上執(zhí)行show slave status命令查看延遲時(shí)間，Seconds_Behind_Master表示延遲的秒數(shù)。

主從同步延遲的原因有哪些？

從庫(kù)機(jī)器性能較差：

主庫(kù)負(fù)責(zé)所有讀寫(xiě)請(qǐng)求，從庫(kù)只用來(lái)備份，會(huì)用性能較差的機(jī)器，執(zhí)行時(shí)間自然較慢。

從庫(kù)壓力更大：

讀寫(xiě)分離后，主庫(kù)負(fù)責(zé)寫(xiě)請(qǐng)求，從庫(kù)負(fù)責(zé)讀請(qǐng)求。
互聯(lián)網(wǎng)應(yīng)用一般讀請(qǐng)求更多，所以從庫(kù)讀壓力更大，占用更多CPU資源。

網(wǎng)絡(luò)延遲：

當(dāng)主庫(kù)的Bin Log文件往從庫(kù)上發(fā)送時(shí)，可能產(chǎn)生網(wǎng)絡(luò)延遲，也會(huì)導(dǎo)致從庫(kù)數(shù)據(jù)跟不上。

主庫(kù)有大事務(wù)：

當(dāng)主庫(kù)上有個(gè)大事務(wù)需要執(zhí)行5分鐘，把Bin Log文件發(fā)送到從庫(kù)，從庫(kù)至少也需要執(zhí)行5分鐘，所以這時(shí)候從庫(kù)就出現(xiàn)了5分鐘的延遲。

主從同步延遲的解決方案？

從庫(kù)機(jī)器性能較差：

把從庫(kù)換成跟主庫(kù)同等規(guī)格的機(jī)器。

從庫(kù)壓力更大：

多搞幾臺(tái)從庫(kù)，分擔(dān)讀請(qǐng)求壓力。

網(wǎng)絡(luò)延遲：

聯(lián)系運(yùn)維或者云服務(wù)提供商解決。

主庫(kù)有大事務(wù)：

把大事務(wù)分割成小事務(wù)執(zhí)行，大事務(wù)不但會(huì)產(chǎn)生從庫(kù)延遲，還可能產(chǎn)生死鎖，降低數(shù)據(jù)庫(kù)并發(fā)性能，所以盡量少用大事務(wù)。

5. 如何提升主從同步性能

從庫(kù)開(kāi)啟多線程復(fù)制

就是在主從同步的最后兩步使用多線程，修改配置 slave_parallel_workers=4，代表開(kāi)啟4個(gè)復(fù)制線程。

修改同步模式，改為異步

主從同步共有三種復(fù)制方式：

全同步復(fù)制：

當(dāng)主庫(kù)執(zhí)行完一個(gè)事務(wù)，并且所有從庫(kù)都執(zhí)行完該事務(wù)后，才給客戶端返回成功。

半同步復(fù)制：

至少有一個(gè)從庫(kù)執(zhí)行完成后，就給客戶端返回成功。

異步復(fù)制：

主庫(kù)執(zhí)行完后，立即返回成功，不關(guān)心從庫(kù)是否執(zhí)行完成。

如果對(duì)數(shù)據(jù)安全性要求沒(méi)那么高，可以把同步模式改成半同步復(fù)制或者異步復(fù)制。

修改從庫(kù)Bin Log配置

修改sync_binlog配置：

sync_binlog=0 ，表示寫(xiě)binlog不立即刷新磁盤(pán)，由系統(tǒng)決定什么時(shí)候刷新磁盤(pán)。

sync_binlog=1，每次寫(xiě)binlog都刷新磁盤(pán)，安全性高，性能差。

sync_binlog=N，寫(xiě)N次binlog才刷新磁盤(pán)。

從庫(kù)對(duì)數(shù)據(jù)安全性要求沒(méi)那么高，可以設(shè)置sync_binlog=0。

修改innodb_flush_log_at_trx_commit配置：

innodb_flush_log_at_trx_commit=0，每隔一秒鐘，把事務(wù)日志刷新到磁盤(pán)。

innodb_flush_log_at_trx_commit=1，每次事務(wù)都刷新到磁盤(pán)。

innodb_flush_log_at_trx_commit=2，每次事務(wù)都不主動(dòng)刷新磁盤(pán)，由系統(tǒng)決定什么時(shí)候刷新磁盤(pán)。

從庫(kù)對(duì)數(shù)據(jù)安全性要求沒(méi)那么高，可以設(shè)置innodb_flush_log_at_trx_commit=2。

知識(shí)點(diǎn)總結(jié)

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

您可能感興趣的文章:

亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

一文詳解MySQL主從同步原理

目錄

1. MySQL主從同步實(shí)現(xiàn)方式