大家好，我是小羽。

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

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

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

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

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

簡(jiǎn)介

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

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

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

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

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

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

形式

一主一從

一主一從

一主多從

一主多從

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

多主一從

多主一從

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

雙主復(fù)制

雙主復(fù)制

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

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

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

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

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

原理

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

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

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

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

過程

工作過程

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

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

工作過程

請(qǐng)求流程

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

• 當(dāng)從服務(wù)器連接主服務(wù)器時(shí)，主服務(wù)器會(huì)創(chuàng)建一個(gè) log dump 線程，用于發(fā)送 binlog 的內(nèi)容。在讀取 binlog 的內(nèi)容的操作中，會(huì)對(duì)象主節(jié)點(diǎn)上的 binlog 加鎖，當(dāng)讀取完成并發(fā)送給從服務(wù)器后解鎖。
• 當(dāng)從節(jié)點(diǎn)上執(zhí)行 start slave 命令之后，從節(jié)點(diǎn)會(huì)創(chuàng)建一個(gè) IO 線程用來連接主節(jié)點(diǎn)，請(qǐng)求主庫中更新 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ù)制

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

異步復(fù)制

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

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

同步復(fù)制

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

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

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

半同步復(fù)制

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

半同步復(fù)制

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

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

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

延遲復(fù)制

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

方式

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

語句復(fù)制

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

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

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

特點(diǎn)：

• 傳輸效率高，減少延遲。
• 在從庫更新不存在的記錄時(shí)，語句賦值不會(huì)失敗。而行復(fù)制會(huì)導(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í)行查詢計(jì)劃。
• 不知道執(zhí)行的到底是什么語句。
• 例如一條更新用戶總積分的語句，需要統(tǒng)計(jì)用戶的所有積分再寫入用戶表。如果是基于語句復(fù)制的話，從庫需要再一次統(tǒng)計(jì)用戶的積分，而基于行復(fù)制就直接更新記錄，無需再統(tǒng)計(jì)用戶積分。

混合類型的復(fù)制

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

配置

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

# 如果在雙主復(fù)制結(jié)構(gòu)中沒有設(shè)置ID的話就會(huì)導(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)程崩潰會(huì)丟失一秒內(nèi)的所有事務(wù)。 
# 為1的話，每次事務(wù)log buffer會(huì)寫入log file并刷新到磁盤。（較為安全） 
# 在崩潰的時(shí)候,僅會(huì)丟失一個(gè)事務(wù)。 
# 為2的話，每次事務(wù)log buffer會(huì)寫入log file，但一秒一次刷新到磁盤 
innodb_flush_logs_at_trx_commit=0 
 
# 阻止從庫崩潰后自動(dòng)啟動(dòng)復(fù)制，給一些時(shí)間來修復(fù)可能的問題， 
# 崩潰后再自動(dòng)復(fù)制可能會(huì)導(dǎo)致更多的問題。并且本身就是不一致的 
skip_slave_start=1  
 
# 是否將從庫同步的事件也記錄到從庫自身的bin-log中 
# 允許備庫將重放的事件也記錄到自身的二進(jìn)制日志中去，可以將備庫當(dāng)做另外一臺(tái)主庫的從庫 
log_slave_update  
 
# 日志過期刪除時(shí)間，延遲嚴(yán)重的話會(huì)導(dǎo)致日志文件占用磁盤 
expire_logs_days=7 

問題

延遲

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

解決方法：

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

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

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

解決方法：

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

注意事項(xiàng)

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

• MySQL 主從復(fù)制是 MySQL 高可用性，高性能(負(fù)載均衡)的基礎(chǔ);
• 簡(jiǎn)單，靈活，部署方式多樣，可以根據(jù)不同業(yè)務(wù)場(chǎng)景部署不同復(fù)制結(jié)構(gòu);
• 復(fù)制過程中應(yīng)該時(shí)刻監(jiān)控復(fù)制狀態(tài)，復(fù)制出錯(cuò)或延時(shí)可能給系統(tǒng)造成影響;
• MySQL 主從復(fù)制目前也存在一些問題，可以根據(jù)需要部署復(fù)制增強(qiáng)功能。

作用

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

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

應(yīng)用場(chǎng)景

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

橫向擴(kuò)展

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

在這個(gè)場(chǎ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)對(duì)應(yīng)的數(shù)據(jù)，而不用影響 Master 節(jié)點(diǎn)的運(yùn)行。

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

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

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

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

拆分訪問

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