看完這篇還不懂 MySQL 主從復(fù)制，可以回家躺平了～
大家好，我是小羽。
我們?cè)谄綍r(shí)工作中，使用最多的數(shù)據(jù)庫(kù)就是 MySQL 了，隨著業(yè)務(wù)的增加，如果單單靠一臺(tái)服務(wù)器的話，負(fù)載過(guò)重，就容易造成宕機(jī)。
這樣我們保存在 MySQL 數(shù)據(jù)庫(kù)的數(shù)據(jù)就會(huì)丟失，那么該怎么解決呢？
其實(shí)在 MySQL 本身就自帶有一個(gè)主從復(fù)制的功能，可以幫助我們實(shí)現(xiàn)負(fù)載均衡和讀寫分離。
對(duì)于主服務(wù)器（Master）來(lái)說(shuō)，主要負(fù)責(zé)寫，從服務(wù)器（Slave）主要負(fù)責(zé)讀，這樣的話，就會(huì)大大減輕壓力，從而提高效率。
接下來(lái)，跟著小羽一起來(lái)看看它都有哪些核心知識(shí)點(diǎn)呢：
簡(jiǎn)介
隨著業(yè)務(wù)的增長(zhǎng)，一臺(tái)數(shù)據(jù)服務(wù)器已經(jīng)滿足不了需求了，負(fù)載過(guò)重。這個(gè)時(shí)候就需要減壓了，實(shí)現(xiàn)負(fù)載均衡讀寫分離，一主一叢或一主多從。
主服務(wù)器只負(fù)責(zé)寫，而從服務(wù)器只負(fù)責(zé)讀，從而提高了效率減輕壓力。
主從復(fù)制可以分為：
主從同步：當(dāng)用戶寫數(shù)據(jù)主服務(wù)器必須和從服務(wù)器同步了才告訴用戶寫入成功，等待時(shí)間比較長(zhǎng)。
主從異步：只要用戶訪問(wèn)寫數(shù)據(jù)主服務(wù)器，立即返回給用戶。
主從半同步：當(dāng)用戶訪問(wèn)寫數(shù)據(jù)主服務(wù)器寫入并同步其中一個(gè)從服務(wù)器就返回給用戶成功。
形式
一主一從
一主多從
一主一從和一主多從是我們現(xiàn)在見(jiàn)的最多的主從架構(gòu)，使用起來(lái)簡(jiǎn)單有效，不僅可以實(shí)現(xiàn) HA，而且還能讀寫分離，進(jìn)而提升集群的并發(fā)能力。
多主一從
多主一從可以將多個(gè) MySQL 數(shù)據(jù)庫(kù)備份到一臺(tái)存儲(chǔ)性能比較好的服務(wù)器上。
雙主復(fù)制
雙主復(fù)制，也就是可以互做主從復(fù)制，每個(gè) master 既是 master，又是另外一臺(tái)服務(wù)器的 salve。這樣任何一方所做的變更，都會(huì)通過(guò)復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫(kù)中。
級(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ù)一致性沒(méi)有負(fù)面影響。
原理
MySQL 主從復(fù)制是基于主服務(wù)器在二進(jìn)制日志跟蹤所有對(duì)數(shù)據(jù)庫(kù)的更改。因此，要進(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ù)器，在備份過(guò)程中主服務(wù)器可以繼續(xù)處理更新。
過(guò)程
工作過(guò)程
MySQL 的主從復(fù)制工作過(guò)程大致如下：
從庫(kù)生成兩個(gè)線程，一個(gè) I/O 線程，一個(gè) SQL 線程；
I/O 線程去請(qǐng)求主庫(kù)的 binlog，并將得到的 binlog 日志寫到 relay log(中繼日志) 文件中；
主庫(kù)會(huì)生成一個(gè) log dump 線程，用來(lái)給從庫(kù) I/O 線程傳 binlog；
SQL 線程會(huì)讀取 relay log 文件中的日志，并解析成具體操作，來(lái)實(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 線程用來(lái)連接主節(jié)點(diǎn)，請(qǐng)求主庫(kù)中更新 binlog。IO 線程接收主節(jié)點(diǎn) binlog dump 進(jìn)程發(fā)來(lái)的更新之后，保存到 relay-log 中。從節(jié)點(diǎn) SQL 線程負(fù)責(zé)讀取 realy-log 中的內(nèi)容，解析成具體的操作執(zhí)行，最終保證主從數(shù)據(jù)的一致性。
類型
異步復(fù)制
一個(gè)主庫(kù)，一個(gè)或多個(gè)從庫(kù)，數(shù)據(jù)異步同步到從庫(kù)。
這種模式下，主節(jié)點(diǎn)不會(huì)主動(dòng)推送數(shù)據(jù)到從節(jié)點(diǎn)，主庫(kù)在執(zhí)行完客戶端提交的事務(wù)后會(huì)立即將結(jié)果返給給客戶端，并不關(guān)心從庫(kù)是否已經(jīng)接收并處理。
這樣就會(huì)有一個(gè)問(wèn)題，主節(jié)點(diǎn)如果崩潰掉了，此時(shí)主節(jié)點(diǎn)上已經(jīng)提交的事務(wù)可能并沒(méi)有傳到從節(jié)點(diǎn)上，如果此時(shí)，強(qiáng)行將從提升為主，可能導(dǎo)致新主節(jié)點(diǎn)上的數(shù)據(jù)不完整。
同步復(fù)制
在 MySQL cluster 中特有的復(fù)制方式。
當(dāng)主庫(kù)執(zhí)行完一個(gè)事務(wù)，然后所有的從庫(kù)都復(fù)制了該事務(wù)并成功執(zhí)行完才返回成功信息給客戶端。
因?yàn)樾枰却袕膸?kù)執(zhí)行完該事務(wù)才能返回成功信息，所以全同步復(fù)制的性能必然會(huì)收到嚴(yán)重的影響。
半同步復(fù)制
在異步復(fù)制的基礎(chǔ)上，確保任何一個(gè)主庫(kù)上的事物在提交之前至少有一個(gè)從庫(kù)已經(jīng)收到該事物并日志記錄下來(lái)。
介于異步復(fù)制和全同步復(fù)制之間，主庫(kù)在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個(gè)從庫(kù)接收到并寫到 relay log 中才返回成功信息給客戶端(只能保證主庫(kù)的 Binlog 至少傳輸?shù)搅艘粋€(gè)從節(jié)點(diǎn)上)，否則需要等待直到超時(shí)時(shí)間然后切換成異步模式再提交。
相對(duì)于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，一定程度的保證了數(shù)據(jù)能成功備份到從庫(kù)，同時(shí)它也造成了一定程度的延遲，但是比全同步模式延遲要低，這個(gè)延遲最少是一個(gè) TCP/IP 往返的時(shí)間。所以，半同步復(fù)制最好在低延時(shí)的網(wǎng)絡(luò)中使用。
半同步模式不是 MySQL 內(nèi)置的，從 MySQL 5.5 開(kāi)始集成，需要 master 和 slave 安裝插件開(kāi)啟半同步模式。
延遲復(fù)制
在異步復(fù)制的基礎(chǔ)上，人為設(shè)定主庫(kù)和從庫(kù)的數(shù)據(jù)同步延遲時(shí)間，即保證數(shù)據(jù)延遲至少是這個(gè)參數(shù)。
方式
MySQL 主從復(fù)制支持兩種不同的日志格式，這兩種日志格式也對(duì)應(yīng)了各自的復(fù)制方式。當(dāng)然也有二者相結(jié)合的混合類型復(fù)制。
語(yǔ)句復(fù)制
基于語(yǔ)句的復(fù)制相當(dāng)于邏輯復(fù)制，即二進(jìn)制日志中記錄了操作的語(yǔ)句，通過(guò)這些語(yǔ)句在從數(shù)據(jù)庫(kù)中重放來(lái)實(shí)現(xiàn)復(fù)制。
這種方式簡(jiǎn)單，二進(jìn)制文件小，傳輸帶寬占用小。但是基于語(yǔ)句更新依賴于其它因素，比如插入數(shù)據(jù)時(shí)利用了時(shí)間戳。
因此在開(kāi)發(fā)當(dāng)中，我們應(yīng)該盡量將業(yè)務(wù)邏輯邏輯放在代碼層，而不應(yīng)該放在 MySQL 中，不易拓展。
特點(diǎn)：
傳輸效率高，減少延遲。
在從庫(kù)更新不存在的記錄時(shí)，語(yǔ)句賦值不會(huì)失敗。而行復(fù)制會(huì)導(dǎo)致失敗，從而更早發(fā)現(xiàn)主從之間的不一致。
設(shè)表里有一百萬(wàn)條數(shù)據(jù)，一條sql更新了所有表，基于語(yǔ)句的復(fù)制僅需要發(fā)送一條sql，而基于行的復(fù)制需要發(fā)送一百萬(wàn)條更新記錄
行數(shù)據(jù)復(fù)制
基于行的復(fù)制相當(dāng)于物理復(fù)制，即二進(jìn)制日志中記錄的實(shí)際更新數(shù)據(jù)的每一行。
這樣導(dǎo)致復(fù)制的壓力比較大，日志占用的空間大，傳輸帶寬占用大。但是這種方式比基于語(yǔ)句的復(fù)制要更加精確。
特點(diǎn)：
不需要執(zhí)行查詢計(jì)劃。
不知道執(zhí)行的到底是什么語(yǔ)句。
例如一條更新用戶總積分的語(yǔ)句，需要統(tǒng)計(jì)用戶的所有積分再寫入用戶表。如果是基于語(yǔ)句復(fù)制的話，從庫(kù)需要再一次統(tǒng)計(jì)用戶的積分，而基于行復(fù)制就直接更新記錄，無(wú)需再統(tǒng)計(jì)用戶積分。
混合類型的復(fù)制
一般情況下，默認(rèn)采用基于語(yǔ)句的復(fù)制，一旦發(fā)現(xiàn)基于語(yǔ)句無(wú)法精確復(fù)制時(shí)，就會(huì)采用基于行的復(fù)制。
配置
配置主要要點(diǎn)如下：
# 如果在雙主復(fù)制結(jié)構(gòu)中沒(méi)有設(shè)置ID的話就會(huì)導(dǎo)致循環(huán)同步問(wèn)題
server_id=1
# 即日志中記錄的是語(yǔ)句還是行更新或者是混合
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
# 阻止從庫(kù)崩潰后自動(dòng)啟動(dòng)復(fù)制，給一些時(shí)間來(lái)修復(fù)可能的問(wèn)題，
# 崩潰后再自動(dòng)復(fù)制可能會(huì)導(dǎo)致更多的問(wèn)題。并且本身就是不一致的
skip_slave_start=1
# 是否將從庫(kù)同步的事件也記錄到從庫(kù)自身的bin-log中
# 允許備庫(kù)將重放的事件也記錄到自身的二進(jìn)制日志中去，可以將備庫(kù)當(dāng)做另外一臺(tái)主庫(kù)的從庫(kù)
log_slave_update
# 日志過(guò)期刪除時(shí)間，延遲嚴(yán)重的話會(huì)導(dǎo)致日志文件占用磁盤
expire_logs_days=7問(wèn)題
延遲
當(dāng)主庫(kù)的 TPS 并發(fā)較高的時(shí)候，由于主庫(kù)上面是多線程寫入的，而從庫(kù)的SQL線程是單線程的，導(dǎo)致從庫(kù)SQL可能會(huì)跟不上主庫(kù)的處理速度。
解決方法：
網(wǎng)絡(luò)方面：盡量保證主庫(kù)和從庫(kù)之間的網(wǎng)絡(luò)穩(wěn)定，延遲較小；
硬件方面：從庫(kù)配置更好的硬件，提升隨機(jī)寫的性能；
配置方面：盡量使 MySQL 的操作在內(nèi)存中完成，減少磁盤操作?；蛏?jí) MySQL5.7 版本使用并行復(fù)制；
建構(gòu)方面：在事務(wù)中盡量對(duì)主庫(kù)讀寫，其它非事務(wù)的讀在從庫(kù)。消除一部分延遲帶來(lái)的數(shù)據(jù)庫(kù)不一致。增加緩存降低一些從庫(kù)的負(fù)載。
數(shù)據(jù)丟失
當(dāng)主庫(kù)宕機(jī)后，數(shù)據(jù)可能丟失。
解決方法：
使用半同步復(fù)制，可以解決數(shù)據(jù)丟失的問(wèn)題。
注意事項(xiàng)
MySQL 需要注意以下事項(xiàng)：
MySQL 主從復(fù)制是 MySQL 高可用性，高性能（負(fù)載均衡）的基礎(chǔ)；
簡(jiǎn)單，靈活，部署方式多樣，可以根據(jù)不同業(yè)務(wù)場(chǎng)景部署不同復(fù)制結(jié)構(gòu)；
復(fù)制過(guò)程中應(yīng)該時(shí)刻監(jiān)控復(fù)制狀態(tài)，復(fù)制出錯(cuò)或延時(shí)可能給系統(tǒng)造成影響；
MySQL 主從復(fù)制目前也存在一些問(wèn)題，可以根據(jù)需要部署復(fù)制增強(qiáng)功能。
作用
主從復(fù)制帶來(lái)了很多好處，當(dāng)我們的主服務(wù)器出現(xiàn)問(wèn)題，可以切換到從服務(wù)器；可以進(jìn)行數(shù)據(jù)庫(kù)層面的讀寫分離；可以在從數(shù)據(jù)庫(kù)上進(jìn)行日常備份。還可以保證：
數(shù)據(jù)更安全：做了數(shù)據(jù)冗余，不會(huì)因?yàn)閱闻_(tái)服務(wù)器的宕機(jī)而丟失數(shù)據(jù)；
性能大大提升：一主多從，不同用戶從不同數(shù)據(jù)庫(kù)讀取，性能提升；
擴(kuò)展性更優(yōu)：流量增大時(shí)，可以方便的增加從服務(wù)器，不影響系統(tǒng)使用；
負(fù)載均衡：一主多從相當(dāng)于分擔(dān)了主機(jī)任務(wù)，做了負(fù)載均衡。
應(yīng)用場(chǎng)景
MySQL 主從復(fù)制集群功能使得 MySQL 數(shù)據(jù)庫(kù)支持大規(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)上完成。通過(guò)增加更多的 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)連接。
拆分訪問(wèn)
可以把幾個(gè)不同的從服務(wù)器，根據(jù)公司的業(yè)務(wù)進(jìn)行拆分。通過(guò)拆分可以幫助減輕主服務(wù)器的壓力，還可以使數(shù)據(jù)庫(kù)對(duì)外部用戶瀏覽、內(nèi)部用戶業(yè)務(wù)處理及 DBA 人員的備份等互不影響。
關(guān)于我
下面的是我的個(gè)人二維碼圖片，希望能跟大家一起進(jìn)階，共同進(jìn)步。
點(diǎn)擊公眾號(hào)，星標(biāo)置頂，小羽的每一次分享都不會(huì)錯(cuò)過(guò)！