面試官：你了解MySQL 主從復(fù)制嗎？
來源｜淺羽的IT小屋
我們在平時(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ù)載均衡和讀寫分離。
對于主服務(wù)器（Master）來說，主要負(fù)責(zé)寫，從服務(wù)器（Slave）主要負(fù)責(zé)讀，這樣的話，就會(huì)大大減輕壓力，從而提高效率。
接下來，跟著小羽一起來看看它都有哪些核心知識點(diǎn)呢：
簡介
隨著業(yè)務(wù)的增長，一臺(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í)間比較長。
主從異步：只要用戶訪問寫數(shù)據(jù)主服務(wù)器，立即返回給用戶。
主從半同步：當(dāng)用戶訪問寫數(shù)據(jù)主服務(wù)器寫入并同步其中一個(gè)從服務(wù)器就返回給用戶成功。
形式
一主一從
一主多從
一主一從和一主多從是我們現(xiàn)在見的最多的主從架構(gòu)，使用起來簡單有效，不僅可以實(shí)現(xiàn) HA，而且還能讀寫分離，進(jìn)而提升集群的并發(fā)能力。
多主一從
多主一從可以將多個(gè) MySQL 數(shù)據(jù)庫備份到一臺(tái)存儲(chǔ)性能比較好的服務(wù)器上。
雙主復(fù)制
雙主復(fù)制，也就是可以互做主從復(fù)制，每個(gè) master 既是 master，又是另外一臺(tái)服務(wù)器的 salve。這樣任何一方所做的變更，都會(huì)通過復(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)，就會(huì)損耗一部分性能用于 replication ，那么我們可以讓 3~5 個(gè)從節(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)制日志。
每個(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ù)制工作過程大致如下：
從庫生成兩個(gè)線程，一個(gè) I/O 線程，一個(gè) SQL 線程；
I/O 線程去請求主庫的 binlog，并將得到的 binlog 日志寫到 relay log(中繼日志) 文件中；
主庫會(huì)生成一個(gè) log dump 線程，用來給從庫 I/O 線程傳 binlog；
SQL 線程會(huì)讀取 relay log 文件中的日志，并解析成具體操作，來實(shí)現(xiàn)主從的操作一致，而最終數(shù)據(jù)一致；
請求流程
MySQL 建立請求的主從的詳細(xì)流程如下：
當(dāng)從服務(wù)器連接主服務(wù)器時(shí)，主服務(wù)器會(huì)創(chuàng)建一個(gè) log dump 線程，用于發(fā)送 binlog 的內(nèi)容。在讀取 binlog 的內(nèi)容的操作中，會(huì)對象主節(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)，請求主庫中更新 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ù)異步同步到從庫。
這種模式下，主節(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ù)制之間，主庫在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個(gè)從庫接收到并寫到 relay log 中才返回成功信息給客戶端(只能保證主庫的 Binlog 至少傳輸?shù)搅艘粋€(gè)從節(jié)點(diǎn)上)，否則需要等待直到超時(shí)時(shí)間然后切換成異步模式再提交。
相對于異步復(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ù)制支持兩種不同的日志格式，這兩種日志格式也對應(yīng)了各自的復(fù)制方式。當(dāng)然也有二者相結(jié)合的混合類型復(fù)制。
語句復(fù)制
基于語句的復(fù)制相當(dāng)于邏輯復(fù)制，即二進(jìn)制日志中記錄了操作的語句，通過這些語句在從數(shù)據(jù)庫中重放來實(shí)現(xiàn)復(fù)制。
這種方式簡單，二進(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)存中完成，減少磁盤操作。或升級 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)該時(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)行日常備份。還可以保證：
數(shù)據(jù)更安全：做了數(shù)據(jù)冗余，不會(huì)因?yàn)閱闻_(tái)服務(wù)器的宕機(jī)而丟失數(shù)據(jù)；
性能大大提升：一主多從，不同用戶從不同數(shù)據(jù)庫讀取，性能提升；
擴(kuò)展性更優(yōu)：流量增大時(shí)，可以方便的增加從服務(wù)器，不影響系統(tǒng)使用；
負(fù)載均衡：一主多從相當(dāng)于分擔(dān)了主機(jī)任務(wù)，做了負(fù)載均衡。
應(yīng)用場景
MySQL 主從復(fù)制集群功能使得 MySQL 數(shù)據(jù)庫支持大規(guī)模高并發(fā)讀寫成為可能，同時(shí)有效地保護(hù)了物理服務(wù)器宕機(jī)場景的數(shù)據(jù)備份。
橫向擴(kuò)展
將工作負(fù)載分發(fā)到各 Slave 節(jié)點(diǎn)上，從而提高系統(tǒng)性能。
在這個(gè)場景下，所有的寫(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í)數(shù)據(jù)可以在 Master 節(jié)點(diǎn)上創(chuàng)建，而分析這些數(shù)據(jù)可以在 Slave 節(jié)點(diǎn)上進(jìn)行，并且不會(huì)對 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ù)庫對外部用戶瀏覽、內(nèi)部用戶業(yè)務(wù)處理及 DBA 人員的備份等互不影響。