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