前言

• 數(shù)據(jù)庫主從概念、優(yōu)點(diǎn)、用途
• 數(shù)據(jù)庫主從復(fù)制原理
• 主主、主從、主備的區(qū)別
• MySQL是怎么保證主從一致的
• 數(shù)據(jù)庫主從延遲的原因與解決方案
• 聊聊數(shù)據(jù)庫的高可用方案

一. 數(shù)據(jù)庫主從概念、優(yōu)點(diǎn)、用途

主從數(shù)據(jù)庫是什么意思呢，主是主庫的意思，從是從庫的意思。數(shù)據(jù)庫主庫對(duì)外提供讀寫的操作，從庫對(duì)外提供讀的操作。

數(shù)據(jù)庫為什么需要主從架構(gòu)呢？

• 高可用，實(shí)時(shí)災(zāi)備，用于故障切換。比如主庫掛了，可以切從庫。
• 讀寫分離，提供查詢服務(wù)，減少主庫壓力，提升性能
• 備份數(shù)據(jù)，避免影響業(yè)務(wù)。

二. 數(shù)據(jù)庫主從復(fù)制原理

主從復(fù)制原理，簡(jiǎn)言之，分三步曲進(jìn)行：

• 主數(shù)據(jù)庫有個(gè)bin log二進(jìn)制文件，紀(jì)錄了所有增刪改SQL語句。（binlog線程）
• 從數(shù)據(jù)庫把主數(shù)據(jù)庫的bin log文件的SQL 語句復(fù)制到自己的中繼日志 relay log（io線程）
• 從數(shù)據(jù)庫的relay log重做日志文件，再執(zhí)行一次這些sql語句。（Sql執(zhí)行線程）

詳細(xì)的主從復(fù)制過程如圖：

從復(fù)制過程分了五個(gè)步驟進(jìn)行：

• 主庫的更新SQL(update、insert、delete)被寫到binlog
• 從庫發(fā)起連接，連接到主庫。
• 此時(shí)主庫創(chuàng)建一個(gè)binlog dump thread，把bin log的內(nèi)容發(fā)送到從庫。
• 從庫啟動(dòng)之后，創(chuàng)建一個(gè)I/O線程，讀取主庫傳過來的bin log內(nèi)容并寫入到relay log
• 從庫還會(huì)創(chuàng)建一個(gè)SQL線程，從relay log里面讀取內(nèi)容，從ExecMasterLog_Pos位置開始執(zhí)行讀取到的更新事件，將更新內(nèi)容寫入到slave的db

三. 主主、主從、主備的區(qū)別

數(shù)據(jù)庫主主：兩臺(tái)都是主數(shù)據(jù)庫，同時(shí)對(duì)外提供讀寫操作?？蛻舳嗽L問任意一臺(tái)。數(shù)據(jù)存在雙向同步。

數(shù)據(jù)庫主從：一臺(tái)是主數(shù)據(jù)庫，同時(shí)對(duì)外提供讀寫操作。一臺(tái)是從數(shù)據(jù)庫，對(duì)外提供讀的操作。數(shù)據(jù)從主庫同步到從庫。

數(shù)據(jù)庫主備：一臺(tái)是主數(shù)據(jù)庫，同時(shí)對(duì)外提供讀寫操作。一臺(tái)是備庫，只作為備份作用，不對(duì)外提供讀寫，主機(jī)掛了它就取而代之。數(shù)據(jù)從主庫同步到備庫。

從庫和備庫，就是slave庫功能不同因此叫法才不一樣而已。一般slave庫都會(huì)對(duì)外提供讀的功能的，因此，大家日常聽得比較多就是主從。

四. MySQL是怎么保證主從一致的

我們學(xué)習(xí)數(shù)據(jù)庫的主從復(fù)制原理后，了解到從庫拿到并執(zhí)行主庫的binlog日志，就可以保持?jǐn)?shù)據(jù)與主庫一致了。這是為什么呢？哪些情況會(huì)導(dǎo)致不一致呢？

4.1 長(zhǎng)鏈接

主庫和從庫在同步數(shù)據(jù)的過程中斷怎么辦呢，數(shù)據(jù)不就會(huì)丟失了嘛。因此主庫與從庫之間維持了一個(gè)長(zhǎng)鏈接，主庫內(nèi)部有一個(gè)線程，專門服務(wù)于從庫的這個(gè)長(zhǎng)鏈接的。

4.2 binlog格式

binlog 日志有三種格式，分別是statement，row和mixed。

如果是statement格式，binlog記錄的是SQL的原文，如果主庫和從庫選的索引不一致，可能會(huì)導(dǎo)致主庫不一致。我們來分析一下。假設(shè)主庫執(zhí)行刪除這個(gè)SQL（其中a和create_time都有索引）如下：

delete from t where a > '666' and create_time<'2022-03-01' limit 1;

我們知道，數(shù)據(jù)庫選擇了a索引和選擇create_time索引，最后limit 1出來的數(shù)據(jù)一般是不一樣的。所以就會(huì)存在這種情況：在binlog = statement格式時(shí)，主庫在執(zhí)行這條SQL時(shí)，使用的是索引a，而從庫在執(zhí)行這條SQL時(shí)，使用了索引create_time。最后主從數(shù)據(jù)不一致了。

如何解決這個(gè)問題呢？

可以把binlog格式修改為row。row格式的binlog日志，記錄的不是SQL原文，而是兩個(gè)event:Table_map 和 Delete_rows。Table_map event說明要操作的表，Delete_rows event用于定義要?jiǎng)h除的行為，記錄刪除的具體行數(shù)。row格式的binlog記錄的就是要?jiǎng)h除的主鍵ID信息，因此不會(huì)出現(xiàn)主從不一致的問題。

但是如果SQL刪除10萬行數(shù)據(jù)，使用row格式就會(huì)很占空間的，10萬條數(shù)據(jù)都在binlog里面，寫binlog的時(shí)候也很耗IO。但是statement格式的binlog可能會(huì)導(dǎo)致數(shù)據(jù)不一致，因此設(shè)計(jì)MySQL的大叔想了一個(gè)折中的方案，mixed格式的binlog。所謂的mixed格式其實(shí)就是row和statement格式混合使用，當(dāng)MySQL判斷可能數(shù)據(jù)不一致時(shí)，就用row格式，否則使用就用statement格式。

五. 數(shù)據(jù)庫主從延遲的原因與解決方案

主從延遲是怎么定義的呢？與主從數(shù)據(jù)同步相關(guān)的時(shí)間點(diǎn)有三個(gè)

• 主庫執(zhí)行完一個(gè)事務(wù)，寫入binlog，我們把這個(gè)時(shí)刻記為T1；
• 主庫同步數(shù)據(jù)給從庫，從庫接收完這個(gè)binlog的時(shí)刻，記錄為T2；
• 從庫執(zhí)行完這個(gè)事務(wù)，這個(gè)時(shí)刻記錄為T3。

所謂主從延遲，其實(shí)就是指同一個(gè)事務(wù)，在從庫執(zhí)行完的時(shí)間和在主庫執(zhí)行完的時(shí)間差值，即T3-T1。

哪些情況會(huì)導(dǎo)致主從延遲呢？

• 如果從庫所在的機(jī)器比主庫的機(jī)器性能差，會(huì)導(dǎo)致主從延遲，這種情況比較好解決，只需選擇主從庫一樣規(guī)格的機(jī)器就好。
• 如果從庫的壓力大，也會(huì)導(dǎo)致主從延遲。比如主庫直接影響業(yè)務(wù)的，大家可能使用會(huì)比較克制，因此一般查詢都打到從庫了，結(jié)果導(dǎo)致從庫查詢消耗大量CPU，影響同步速度，最后導(dǎo)致主從延遲。這種情況的話，可以搞了一主多從的架構(gòu)，即多接幾個(gè)從庫分?jǐn)傋x的壓力。另外，還可以把binlog接入到Hadoop這類系統(tǒng)，讓它們提供查詢的能力。
• 大事務(wù)也會(huì)導(dǎo)致主從延遲。如果一個(gè)事務(wù)執(zhí)行就要10分鐘，那么主庫執(zhí)行完后，給到從庫執(zhí)行，最后這個(gè)事務(wù)可能就會(huì)導(dǎo)致從庫延遲10分鐘啦。日常開發(fā)中，我們?yōu)槭裁刺貏e強(qiáng)調(diào)，不要一次性delete太多SQL，需要分批進(jìn)行，其實(shí)也是為了避免大事務(wù)。另外，大表的DDL語句，也會(huì)導(dǎo)致大事務(wù)，大家日常開發(fā)關(guān)注一下哈。
• 網(wǎng)絡(luò)延遲也會(huì)導(dǎo)致主從延遲，這種情況你只能優(yōu)化你的網(wǎng)絡(luò)啦，比如帶寬20M升級(jí)到100M類似意思等。
• 如果從數(shù)據(jù)庫過多也會(huì)導(dǎo)致主從延遲，因此要避免復(fù)制的從節(jié)點(diǎn)數(shù)量過多。從庫數(shù)據(jù)一般以3-5個(gè)為宜。
• 低版本的MySQL只支持單線程復(fù)制，如果主庫并發(fā)高，來不及傳送到從庫，就會(huì)導(dǎo)致延遲?？梢該Q用更高版本的Mysql，可以支持多線程復(fù)制。

   六. 聊聊數(shù)據(jù)的庫高可用方案

• 雙機(jī)主備
• 一主一從
• 一主多從
• MariaDB同步多主機(jī)
• 數(shù)據(jù)庫中間件

6.1 雙機(jī)主備高可用

• 架構(gòu)描述：兩臺(tái)機(jī)器A和B，A為主庫，負(fù)責(zé)讀寫，B為備庫，只備份數(shù)據(jù)。如果A庫發(fā)生故障，B庫成為主庫負(fù)責(zé)讀寫。修復(fù)故障后，A成為備庫，主庫B同步數(shù)據(jù)到備庫A
• 優(yōu)點(diǎn)：一個(gè)機(jī)器故障了可以自動(dòng)切換，操作比較簡(jiǎn)單。
• 缺點(diǎn)：只有一個(gè)庫在工作，讀寫壓力大，未能實(shí)現(xiàn)讀寫分離，并發(fā)也有一定限制

6.2 一主一從

• 架構(gòu)描述: 兩臺(tái)機(jī)器A和B，A為主庫，負(fù)責(zé)讀寫，B為從庫，負(fù)責(zé)讀數(shù)據(jù)。如果A庫發(fā)生故障，B庫成為主庫負(fù)責(zé)讀寫。修復(fù)故障后，A成為從庫，主庫B同步數(shù)據(jù)到從庫A。
• 優(yōu)點(diǎn)：從庫支持讀，分擔(dān)了主庫的壓力，提升了并發(fā)度。一個(gè)機(jī)器故障了可以自動(dòng)切換，操作比較簡(jiǎn)單。
• 缺點(diǎn)：一臺(tái)從庫，并發(fā)支持還是不夠，并且一共兩臺(tái)機(jī)器，還是存在同時(shí)故障的機(jī)率，不夠高可用。

6.3 一主多從

• 架構(gòu)描述: 一臺(tái)主庫多臺(tái)從庫，A為主庫，負(fù)責(zé)讀寫，B、C、D為從庫，負(fù)責(zé)讀數(shù)據(jù)。如果A庫發(fā)生故障，B庫成為主庫負(fù)責(zé)讀寫，C、D負(fù)責(zé)讀。修復(fù)故障后，A也成為從庫，主庫B同步數(shù)據(jù)到從庫A。
• 優(yōu)點(diǎn)：多個(gè)從庫支持讀，分擔(dān)了主庫的壓力，明顯提升了讀的并發(fā)度。
• 缺點(diǎn)：只有臺(tái)主機(jī)寫，因此寫的并發(fā)度不高

6.4 MariaDB同步多主機(jī)集群

• 架構(gòu)描述:有代理層實(shí)現(xiàn)負(fù)載均衡，多個(gè)數(shù)據(jù)庫可以同時(shí)進(jìn)行讀寫操作；各個(gè)數(shù)據(jù)庫之間可以通過Galera Replication方法進(jìn)行數(shù)據(jù)同步，每個(gè)庫理論上數(shù)據(jù)是完全一致的。
• 優(yōu)點(diǎn)：讀寫的并發(fā)度都明顯提升，可以任意節(jié)點(diǎn)讀寫，可以自動(dòng)剔除故障節(jié)點(diǎn)，具有較高的可靠性。
• 缺點(diǎn)：數(shù)據(jù)量不支持特別大。要避免大事務(wù)卡死，如果集群節(jié)點(diǎn)一個(gè)變慢，其他節(jié)點(diǎn)也會(huì)跟著變慢。

6.5 數(shù)據(jù)庫中間件

• 架構(gòu)描述：mycat分片存儲(chǔ)，每個(gè)分片配置一主多從的集群。
• 優(yōu)點(diǎn)：解決高并發(fā)高數(shù)據(jù)量的高可用方案
• 缺點(diǎn)：維護(hù)成本比較大。

參考與感謝

• 極客時(shí)間《MySQL45講》
• 數(shù)據(jù)庫高可用方案[1]