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

作者：淺羽Eric 2021-05-28 11:54:29

數(shù)據(jù)庫 MySQL

隨著業(yè)務(wù)的增長，一臺數(shù)據(jù)服務(wù)器已經(jīng)滿足不了需求了，負(fù)載過重。這個時候就需要減壓了，實(shí)現(xiàn)負(fù)載均衡讀寫分離，一主一叢或一主多從。

大家好，我是小羽。

我們在平時工作中，使用最多的數(shù)據(jù)庫就是 MySQL 了，隨著業(yè)務(wù)的增加，如果單單靠一臺服務(wù)器的話，負(fù)載過重，就容易造成宕機(jī)。

這樣我們保存在 MySQL 數(shù)據(jù)庫的數(shù)據(jù)就會丟失，那么該怎么解決呢?

其實(shí)在 MySQL 本身就自帶有一個主從復(fù)制的功能，可以幫助我們實(shí)現(xiàn)負(fù)載均衡和讀寫分離。

對于主服務(wù)器(Master)來說，主要負(fù)責(zé)寫，從服務(wù)器(Slave)主要負(fù)責(zé)讀，這樣的話，就會大大減輕壓力，從而提高效率。

接下來，跟著小羽一起來看看它都有哪些核心知識點(diǎn)呢：

簡介

主服務(wù)器只負(fù)責(zé)寫，而從服務(wù)器只負(fù)責(zé)讀，從而提高了效率減輕壓力。

主從復(fù)制可以分為：

主從同步：當(dāng)用戶寫數(shù)據(jù)主服務(wù)器必須和從服務(wù)器同步了才告訴用戶寫入成功，等待時間比較長。

主從異步：只要用戶訪問寫數(shù)據(jù)主服務(wù)器，立即返回給用戶。

主從半同步：當(dāng)用戶訪問寫數(shù)據(jù)主服務(wù)器寫入并同步其中一個從服務(wù)器就返回給用戶成功。

形式

一主一從

一主多從

一主一從和一主多從是我們現(xiàn)在見的最多的主從架構(gòu)，使用起來簡單有效，不僅可以實(shí)現(xiàn) HA，而且還能讀寫分離，進(jìn)而提升集群的并發(fā)能力。

多主一從

多主一從可以將多個 MySQL 數(shù)據(jù)庫備份到一臺存儲性能比較好的服務(wù)器上。

雙主復(fù)制

雙主復(fù)制，也就是可以互做主從復(fù)制，每個 master 既是 master，又是另外一臺服務(wù)器的 salve。這樣任何一方所做的變更，都會通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫中。

級聯(lián)復(fù)制

級聯(lián)復(fù)制模式下，部分 slave 的數(shù)據(jù)同步不連接主節(jié)點(diǎn)，而是連接從節(jié)點(diǎn)。

因?yàn)槿绻鞴?jié)點(diǎn)有太多的從節(jié)點(diǎn)，就會損耗一部分性能用于 replication ，那么我們可以讓 3~5 個從節(jié)點(diǎn)連接主節(jié)點(diǎn)，其它從節(jié)點(diǎn)作為二級或者三級與從節(jié)點(diǎn)連接，這樣不僅可以緩解主節(jié)點(diǎn)的壓力，并且對數(shù)據(jù)一致性沒有負(fù)面影響。

原理

MySQL 主從復(fù)制是基于主服務(wù)器在二進(jìn)制日志跟蹤所有對數(shù)據(jù)庫的更改。因此，要進(jìn)行復(fù)制，必須在主服務(wù)器上啟用二進(jìn)制日志。

每個從服務(wù)器從主服務(wù)器接收已經(jīng)記錄到日志的數(shù)據(jù)。當(dāng)一個從服務(wù)器連接到主服務(wù)器時，它通知主服務(wù)器從服務(wù)器日志中讀取最后一個更新成功的位置。

從服務(wù)器接收從那時發(fā)生起的任何更新，并在主機(jī)上執(zhí)行相同的更新。然后封鎖等待主服務(wù)器通知的更新。

從服務(wù)器執(zhí)行備份不會干擾主服務(wù)器，在備份過程中主服務(wù)器可以繼續(xù)處理更新。

過程

工作過程

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

從庫生成兩個線程，一個 I/O 線程，一個 SQL 線程;
I/O 線程去請求主庫的 binlog，并將得到的 binlog 日志寫到 relay log(中繼日志) 文件中;
主庫會生成一個 log dump 線程，用來給從庫 I/O 線程傳 binlog;
SQL 線程會讀取 relay log 文件中的日志，并解析成具體操作，來實(shí)現(xiàn)主從的操作一致，而最終數(shù)據(jù)一致;

工作過程

請求流程

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

當(dāng)從服務(wù)器連接主服務(wù)器時，主服務(wù)器會創(chuàng)建一個 log dump 線程，用于發(fā)送 binlog 的內(nèi)容。在讀取 binlog 的內(nèi)容的操作中，會對象主節(jié)點(diǎn)上的 binlog 加鎖，當(dāng)讀取完成并發(fā)送給從服務(wù)器后解鎖。
當(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 中。
從節(jié)點(diǎn) SQL 線程負(fù)責(zé)讀取 realy-log 中的內(nèi)容，解析成具體的操作執(zhí)行，最終保證主從數(shù)據(jù)的一致性。

類型

異步復(fù)制

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

異步復(fù)制

這種模式下，主節(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ù)制和全同步復(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ù)。

方式

MySQL 主從復(fù)制支持兩種不同的日志格式，這兩種日志格式也對應(yīng)了各自的復(fù)制方式。當(dāng)然也有二者相結(jié)合的混合類型復(fù)制。

語句復(fù)制

基于語句的復(fù)制相當(dāng)于邏輯復(fù)制，即二進(jìn)制日志中記錄了操作的語句，通過這些語句在從數(shù)據(jù)庫中重放來實(shí)現(xiàn)復(fù)制。

這種方式簡單，二進(jìn)制文件小，傳輸帶寬占用小。但是基于語句更新依賴于其它因素，比如插入數(shù)據(jù)時利用了時間戳。

因此在開發(fā)當(dāng)中，我們應(yīng)該盡量將業(yè)務(wù)邏輯邏輯放在代碼層，而不應(yīng)該放在 MySQL 中，不易拓展。

特點(diǎn)：

傳輸效率高，減少延遲。
在從庫更新不存在的記錄時，語句賦值不會失敗。而行復(fù)制會導(dǎo)致失敗，從而更早發(fā)現(xiàn)主從之間的不一致。
設(shè)表里有一百萬條數(shù)據(jù)，一條sql更新了所有表，基于語句的復(fù)制僅需要發(fā)送一條sql，而基于行的復(fù)制需要發(fā)送一百萬條更新記錄

行數(shù)據(jù)復(fù)制

基于行的復(fù)制相當(dāng)于物理復(fù)制，即二進(jìn)制日志中記錄的實(shí)際更新數(shù)據(jù)的每一行。

這樣導(dǎo)致復(fù)制的壓力比較大，日志占用的空間大，傳輸帶寬占用大。但是這種方式比基于語句的復(fù)制要更加精確。

特點(diǎn)：

不需要執(zhí)行查詢計劃。
不知道執(zhí)行的到底是什么語句。
例如一條更新用戶總積分的語句，需要統(tǒng)計用戶的所有積分再寫入用戶表。如果是基于語句復(fù)制的話，從庫需要再一次統(tǒng)計用戶的積分，而基于行復(fù)制就直接更新記錄，無需再統(tǒng)計用戶積分。

混合類型的復(fù)制

一般情況下，默認(rèn)采用基于語句的復(fù)制，一旦發(fā)現(xiàn)基于語句無法精確復(fù)制時，就會采用基于行的復(fù)制。

配置

配置主要要點(diǎn)如下：

# 如果在雙主復(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

問題

延遲

當(dāng)主庫的 TPS 并發(fā)較高的時候，由于主庫上面是多線程寫入的，而從庫的SQL線程是單線程的，導(dǎo)致從庫SQL可能會跟不上主庫的處理速度。

解決方法：

網(wǎng)絡(luò)方面：盡量保證主庫和從庫之間的網(wǎng)絡(luò)穩(wěn)定，延遲較小;
硬件方面：從庫配置更好的硬件，提升隨機(jī)寫的性能;
配置方面：盡量使 MySQL 的操作在內(nèi)存中完成，減少磁盤操作。或升級 MySQL5.7 版本使用并行復(fù)制;
建構(gòu)方面：在事務(wù)中盡量對主庫讀寫，其它非事務(wù)的讀在從庫。消除一部分延遲帶來的數(shù)據(jù)庫不一致。增加緩存降低一些從庫的負(fù)載。

數(shù)據(jù)丟失

當(dāng)主庫宕機(jī)后，數(shù)據(jù)可能丟失。

解決方法：

使用半同步復(fù)制，可以解決數(shù)據(jù)丟失的問題。

注意事項(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)功能。

作用

主從復(fù)制帶來了很多好處，當(dāng)我們的主服務(wù)器出現(xiàn)問題，可以切換到從服務(wù)器;可以進(jìn)行數(shù)據(jù)庫層面的讀寫分離;可以在從數(shù)據(jù)庫上進(jìn)行日常備份。還可以保證：

數(shù)據(jù)更安全：做了數(shù)據(jù)冗余，不會因?yàn)閱闻_服務(wù)器的宕機(jī)而丟失數(shù)據(jù);
性能大大提升：一主多從，不同用戶從不同數(shù)據(jù)庫讀取，性能提升;
擴(kuò)展性更優(yōu)：流量增大時，可以方便的增加從服務(wù)器，不影響系統(tǒng)使用;
負(fù)載均衡：一主多從相當(dāng)于分擔(dān)了主機(jī)任務(wù)，做了負(fù)載均衡。

應(yī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)行。