看完這篇還不懂 MySQL 主從復(fù)制，可以回家躺平了～

過程

工作過程

MySQL 的主從復(fù)制工作過程大致如下：

1. 從庫生成兩個線程，一個 I/O 線程，一個 SQL 線程；

2. I/O 線程去請求主庫的 binlog，并將得到的 binlog 日志寫到 relay log(中繼日志) 文件中；

3. 主庫會生成一個 log dump 線程，用來給從庫 I/O 線程傳 binlog；

4. SQL 線程會讀取 relay log 文件中的日志，并解析成具體操作，來實(shí)現(xiàn)主從的操作一致，而最終數(shù)據(jù)一致；

請求流程

MySQL 建立請求的主從的詳細(xì)流程如下：

1. 當(dāng)從服務(wù)器連接主服務(wù)器時，主服務(wù)器會創(chuàng)建一個 log dump 線程，用于發(fā)送 binlog 的內(nèi)容。在讀取 binlog 的內(nèi)容的操作中，會對象主節(jié)點(diǎn)上的 binlog 加鎖，當(dāng)讀取完成并發(fā)送給從服務(wù)器后解鎖。

2. 當(dāng)從節(jié)點(diǎn)上執(zhí)行 start slave 命令之后，從節(jié)點(diǎn)會創(chuàng)建一個 IO 線程用來連接主節(jié)點(diǎn)，請求主庫中更新 binlog。IO 線程接收主節(jié)點(diǎn) binlog dump 進(jìn)程發(fā)來的更新之后，保存到 relay-log 中。

3. 從節(jié)點(diǎn) SQL 線程負(fù)責(zé)讀取 realy-log 中的內(nèi)容，解析成具體的操作執(zhí)行，最終保證主從數(shù)據(jù)的一致性。

異步復(fù)制

一個主庫，一個或多個從庫，數(shù)據(jù)異步同步到從庫。

這種模式下，主節(jié)點(diǎn)不會主動推送數(shù)據(jù)到從節(jié)點(diǎn)，主庫在執(zhí)行完客戶端提交的事務(wù)后會立即將結(jié)果返給給客戶端，并不關(guān)心從庫是否已經(jīng)接收并處理。

這樣就會有一個問題，主節(jié)點(diǎn)如果崩潰掉了，此時主節(jié)點(diǎn)上已經(jīng)提交的事務(wù)可能并沒有傳到從節(jié)點(diǎn)上，如果此時，強(qiáng)行將從提升為主，可能導(dǎo)致新主節(jié)點(diǎn)上的數(shù)據(jù)不完整。

同步復(fù)制

在 MySQL cluster 中特有的復(fù)制方式。

當(dāng)主庫執(zhí)行完一個事務(wù)，然后所有的從庫都復(fù)制了該事務(wù)并成功執(zhí)行完才返回成功信息給客戶端。

因?yàn)樾枰却袕膸靾?zhí)行完該事務(wù)才能返回成功信息，所以全同步復(fù)制的性能必然會收到嚴(yán)重的影響。

半同步復(fù)制

在異步復(fù)制的基礎(chǔ)上，確保任何一個主庫上的事物在提交之前至少有一個從庫已經(jīng)收到該事物并日志記錄下來。

介于異步復(fù)制和全同步復(fù)制之間，主庫在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個從庫接收到并寫到 relay log 中才返回成功信息給客戶端(只能保證主庫的 Binlog 至少傳輸?shù)搅艘粋€從節(jié)點(diǎn)上)，否則需要等待直到超時時間然后切換成異步模式再提交。

相對于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，一定程度的保證了數(shù)據(jù)能成功備份到從庫，同時它也造成了一定程度的延遲，但是比全同步模式延遲要低，這個延遲最少是一個 TCP/IP 往返的時間。所以，半同步復(fù)制最好在低延時的網(wǎng)絡(luò)中使用。

半同步模式不是 MySQL 內(nèi)置的，從 MySQL 5.5 開始集成，需要 master 和 slave 安裝插件開啟半同步模式。

延遲復(fù)制

在異步復(fù)制的基礎(chǔ)上，人為設(shè)定主庫和從庫的數(shù)據(jù)同步延遲時間，即保證數(shù)據(jù)延遲至少是這個參數(shù)。

# 如果在雙主復(fù)制結(jié)構(gòu)中沒有設(shè)置ID的話就會導(dǎo)致循環(huán)同步問題
server_id=1

# 即日志中記錄的是語句還是行更新或者是混合
binlog_format=mixed

# 在進(jìn)行n次事務(wù)提交以后，Mysql將執(zhí)行一次fsync的磁盤同步指令。將緩沖區(qū)數(shù)據(jù)刷新到磁盤。
# 為0的話由Mysql自己控制頻率。
sync_binlog=n

# 為0的話，log buffer將每秒一次地寫入log file中并且刷新到磁盤。
# mysqld進(jìn)程崩潰會丟失一秒內(nèi)的所有事務(wù)。
# 為1的話，每次事務(wù)log buffer會寫入log file并刷新到磁盤。（較為安全）
# 在崩潰的時候,僅會丟失一個事務(wù)。
# 為2的話，每次事務(wù)log buffer會寫入log file，但一秒一次刷新到磁盤
innodb_flush_logs_at_trx_commit=0

# 阻止從庫崩潰后自動啟動復(fù)制，給一些時間來修復(fù)可能的問題，
# 崩潰后再自動復(fù)制可能會導(dǎo)致更多的問題。并且本身就是不一致的
skip_slave_start=1 

# 是否將從庫同步的事件也記錄到從庫自身的bin-log中
# 允許備庫將重放的事件也記錄到自身的二進(jìn)制日志中去，可以將備庫當(dāng)做另外一臺主庫的從庫
log_slave_update 

# 日志過期刪除時間，延遲嚴(yán)重的話會導(dǎo)致日志文件占用磁盤
expire_logs_days=7

注意事項(xiàng)

MySQL 需要注意以下事項(xiàng)：

• MySQL 主從復(fù)制是 MySQL 高可用性，高性能（負(fù)載均衡）的基礎(chǔ)；

• 簡單，靈活，部署方式多樣，可以根據(jù)不同業(yè)務(wù)場景部署不同復(fù)制結(jié)構(gòu)；

• 復(fù)制過程中應(yīng)該時刻監(jiān)控復(fù)制狀態(tài)，復(fù)制出錯或延時可能給系統(tǒng)造成影響；

• MySQL 主從復(fù)制目前也存在一些問題，可以根據(jù)需要部署復(fù)制增強(qiáng)功能。

MySQL 主從復(fù)制集群功能使得 MySQL 數(shù)據(jù)庫支持大規(guī)模高并發(fā)讀寫成為可能，同時有效地保護(hù)了物理服務(wù)器宕機(jī)場景的數(shù)據(jù)備份。

橫向擴(kuò)展

將工作負(fù)載分發(fā)到各 Slave 節(jié)點(diǎn)上，從而提高系統(tǒng)性能。

在這個場景下，所有的寫(write)和更新(update)操作都在 Master 節(jié)點(diǎn)上完成；所有的讀( read)操作都在 Slave 節(jié)點(diǎn)上完成。通過增加更多的 Slave 節(jié)點(diǎn)，便能提高系統(tǒng)的讀取速度。

數(shù)據(jù)安全

數(shù)據(jù)從 Master 節(jié)點(diǎn)復(fù)制到 Slave 節(jié)點(diǎn)上，在 Slave 節(jié)點(diǎn)上可以暫停復(fù)制進(jìn)程。可以在 Slave 節(jié)點(diǎn)上備份與 Master 節(jié)點(diǎn)對應(yīng)的數(shù)據(jù)，而不用影響 Master 節(jié)點(diǎn)的運(yùn)行。

數(shù)據(jù)分析

實(shí)時數(shù)據(jù)可以在 Master 節(jié)點(diǎn)上創(chuàng)建，而分析這些數(shù)據(jù)可以在 Slave 節(jié)點(diǎn)上進(jìn)行，并且不會對 Master 節(jié)點(diǎn)的性能產(chǎn)生影響。

遠(yuǎn)距離數(shù)據(jù)分布

可以利用復(fù)制在遠(yuǎn)程主機(jī)上創(chuàng)建一份本地?cái)?shù)據(jù)的副本，而不用持久的與Master節(jié)點(diǎn)連接。

拆分訪問

可以把幾個不同的從服務(wù)器，根據(jù)公司的業(yè)務(wù)進(jìn)行拆分。通過拆分可以幫助減輕主服務(wù)器的壓力，還可以使數(shù)據(jù)庫對外部用戶瀏覽、內(nèi)部用戶業(yè)務(wù)處理及 DBA 人員的備份等互不影響。