面試高頻：MySQL是怎么保證高可用的？
微信搜 歡少的成長之路
介紹
大家好，我是Leo，從事Java后端開發(fā)。之前的文章大概介紹了主從庫的數(shù)據(jù)一致性問題，通過分析binlog的三種格式的優(yōu)缺點以及應(yīng)用性效率。介紹了主從同步的循環(huán)復(fù)制問題以及解決方案。如果不太清楚的小伙伴可以【關(guān)注公眾號：歡少的成長之路】。今天這里主要介紹一下MySQL高可用這一塊的知識。
思路
根據(jù)讀者和用戶的反饋，畫了一個寫作思路圖。通過此圖可以更好的分析出當(dāng)前文章的寫作知識點。可以更快的幫助讀者在最短時間內(nèi)判斷是否為有效文章！
正題
主從延遲
先說一下為什么會有主庫延遲這個問題。隨著互聯(lián)網(wǎng)業(yè)務(wù)數(shù)量量越來越大，伴隨著我們數(shù)據(jù)庫的DB能力也要隨之增強(qiáng)。當(dāng)下最貼合生產(chǎn)數(shù)據(jù)庫模式的應(yīng)該也就是主從庫+讀寫分離+緩存中間件等一系列的解決方案。我們這里只講一下MySQL的本身問題。
如上圖所示，A是主庫，B是從庫。提到高可用問題，肯定不能A一直是主庫，B一直是從庫。所以就存在了主從切換的問題。下面介紹一下切換的流程。
主從A在執(zhí)行一個事務(wù)的時候，寫入binlog日志，我們把這個步驟記為T1。
之后主庫A為了同步，把binlog日志傳給從庫B，備庫B接收完這個binlog我們記為T2。
最終備庫B執(zhí)行這個binlog同步數(shù)據(jù)，我們記為T3
所謂的主從延遲就是在執(zhí)行同一個事務(wù)的時候，在備庫執(zhí)行完成的時間和主庫執(zhí)行完成的時間之間的差值，也就是 T3-T1。
你可以在備庫上執(zhí)行 show slave status 命令，它的返回結(jié)果里面會顯示 seconds_behind_master，用于表示當(dāng)前備庫延遲了多少秒。
可以看到，seconds_behind_master 就是就是主庫執(zhí)行的時間 - 從庫執(zhí)行的時間差。這個值的精準(zhǔn)度是精確到秒的。這里有個很有意思的函數(shù)，我們介紹一下。這個函數(shù)也幫我們解決了時間一致性的問題
SELECT UNIX_TIMESTAMP()
主從庫在做數(shù)據(jù)同步的時候，會通過以上函數(shù)來獲取當(dāng)前主庫的系統(tǒng)時間，如果這時候發(fā)現(xiàn)主庫的系統(tǒng)時間與自己不一致，備庫在執(zhí)行 seconds_behind_master 計算的時候會自動扣掉這個差值。
在網(wǎng)絡(luò)正常的情況下，主從傳給備庫的binlog是很短的。所以主要延遲來源于從庫接收完binlog和執(zhí)行完這個事務(wù)之間的時間差。
主從延遲來源
硬件問題
第一種可能就是硬件問題，一些小公司會考慮把多個備庫放在一臺機(jī)器上，把少量的主庫放在一臺機(jī)器上。認(rèn)為讀庫的需求比寫庫小。其實不是這樣的。從庫要做到數(shù)據(jù)同步一致性，所以更新請求的IPOS的壓力是差不多的。
解決方案： 我們一般采用對稱部署。就是主庫與從庫采用相同規(guī)格的服務(wù)器進(jìn)行部署使用！
壓力過大
主庫提供寫的能力，所以很多人員對主庫一般都是小心翼翼的。導(dǎo)致測試的請求都打到了備庫上，導(dǎo)致備庫壓力過大，在處理數(shù)據(jù)的時候產(chǎn)生延遲。
解決方案： 這種情況可以這樣處理
一主多從。除了備庫外，可以多接幾個從庫，讓這些從庫來分擔(dān)讀的壓力。
通過 binlog 輸出到外部系統(tǒng)，比如 Hadoop 這類系統(tǒng)，讓外部系統(tǒng)提供統(tǒng)計類查詢的能力。
大事務(wù)
這種情況就是非常好理解的了。比如我們在一個主庫刪除一些歷史數(shù)據(jù)。主庫上必須等操作執(zhí)行完全之后才會寫入binlog，然后再傳給從庫。所以如果主庫上執(zhí)行10分鐘，那么備份到從庫上也會執(zhí)行10分鐘。
這里理解不了的話，我們可以查看上一篇的binlog組成。主要有三種格式，row，statement，mixed。在執(zhí)行binlog的時候會執(zhí)行大量的數(shù)據(jù)。
大表DDL
大表DDL的話，我們之前在描述刪除《表數(shù)據(jù)，為什么空間沒變》的時候大概介紹了一些。如果有不清楚的可以關(guān)注【微信公眾號：歡少的成長之路】。
如果對很大的表來說，操作DDL是很消耗IO和CPU資源的。所以我們一般建議使用gh-ost 方案進(jìn)行。
從庫復(fù)制能力
最后一種原因就是從庫的并行復(fù)制能力。這個知識點，我們在后續(xù)再進(jìn)行介紹，東西比較多！
可靠性優(yōu)先策略
介紹一下MySQL的可靠性優(yōu)先策略。這里主要處理的是 主從庫的選擇問題。具體的流程如下
判斷備庫B的
seconds_behind_master是否小于某個值，如果大于某個值的話延遲太大會影響業(yè)務(wù)數(shù)據(jù)的，所以一定要小于某個值的時候才可以繼續(xù)下一步把主庫A改成只讀狀態(tài)，readonly改為true
再判斷
seconds_behind_master的值，直到這個值變成0為止。把備庫B改成讀寫狀態(tài)，也就是把readonly改為flase
最后把業(yè)務(wù)的請求都打到B上
如上圖所示：SBM就是seconds_behind_master的縮寫。
可以看到，這個過程是有不可用時間的。當(dāng)把主庫A改成readonly的時候，同步給從庫B的時候。從庫B也改成了readonly。那么這段時間主從庫都是不可寫的。直接從庫B恢復(fù)完binlog才正常執(zhí)行。
最耗時的是在從庫B執(zhí)行binlog日志的時候，這也是為什么需要第一步先判斷SBM的原因。只有確保延遲足夠小。在后續(xù)中才會縮小誤差。
可用性優(yōu)先策略
除了可靠性優(yōu)先策略，還有一個策略是可用性優(yōu)先策略。
如果我不把數(shù)據(jù)同步完成之后，就直接把訪問切過去，那幾乎就沒有不可用時間了。我們把這個過程稱為可用性優(yōu)先策略。但是另一個弊端就暴露出來了，無法保證數(shù)據(jù)一致問題。
舉例說明一下
假設(shè)有一個表 t，并且插入三行數(shù)據(jù)：
mysql> CREATE TABLE `t` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`c` int(11) unsigned DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(c) values(1),(2),(3);
這個表定義了一個自增主鍵 id，初始化數(shù)據(jù)后，主庫和備庫上都是 3 行數(shù)據(jù)。接下來，業(yè)務(wù)人員要繼續(xù)在表 t 上執(zhí)行兩條插入語句的命令，依次是：
insert into t(c) values(4);
insert into t(c) values(5);
假設(shè)，現(xiàn)在主庫上其他的數(shù)據(jù)表有大量的更新，導(dǎo)致主備延遲達(dá)到 5 秒。在插入一條 c=4 的語句后，發(fā)起了主備切換。如下圖，可用性優(yōu)先策略且binlog_format=mixed的流程
步驟 2 中，主庫 A 執(zhí)行完 insert 語句，插入了一行數(shù)據(jù)（4,4），之后開始進(jìn)行主備切換。
步驟 3 中，由于主備之間有 5 秒的延遲，所以備庫 B 還沒來得及應(yīng)用“插入 c=4”這個中轉(zhuǎn)日志，就開始接收客戶端“插入 c=5”的命令。
步驟 4 中，備庫 B 插入了一行數(shù)據(jù)（4,5），并且把這個 binlog 發(fā)給主庫 A。
步驟 5 中，備庫 B 執(zhí)行“插入 c=4”這個中轉(zhuǎn)日志，插入了一行數(shù)據(jù)（5,4）。而直接在備庫 B 執(zhí)行的“插入 c=5”這個語句，傳到主庫 A，就插入了一行新數(shù)據(jù)（5,5）。
最后的結(jié)果就是，主庫 A 和備庫 B 上出現(xiàn)了兩行不一致的數(shù)據(jù)?？梢钥吹剑@個數(shù)據(jù)不一致，是由可用性優(yōu)先流程導(dǎo)致的。
那么，如果我還是用可用性優(yōu)先策略，但設(shè)置 binlog_format=row，情況又會怎樣呢？
因為 row 格式在記錄 binlog 的時候，會記錄新插入的行的所有字段值，所以最后只會有一行不一致。而且，兩邊的主備同步的應(yīng)用線程會報錯 duplicate key error 并停止。也就是說，這種情況下，備庫 B 的 (5,4) 和主庫 A 的 (5,5) 這兩行數(shù)據(jù)，都不會被對方執(zhí)行。
使用 row 格式的 binlog 時，數(shù)據(jù)不一致的問題更容易被發(fā)現(xiàn)。而使用 mixed 或者 statement 格式的 binlog 時，數(shù)據(jù)很可能悄悄地就不一致了。如果你過了很久才發(fā)現(xiàn)數(shù)據(jù)不一致的問題，很可能這時的數(shù)據(jù)不一致已經(jīng)不可查，或者連帶造成了更多的數(shù)據(jù)邏輯不一致。
主備切換的可用性優(yōu)先策略會導(dǎo)致數(shù)據(jù)不一致。因此，大多數(shù)情況下，我都建議你使用可靠性優(yōu)先策略。畢竟對數(shù)據(jù)服務(wù)來說的話，數(shù)據(jù)的可靠性一般還是要優(yōu)于可用性的。
按照可靠性優(yōu)先的思路，異常切換會是什么效果？
假設(shè)，主庫 A 和備庫 B 間的主備延遲是 30 分鐘，這時候主庫 A 掉電了，HA 系統(tǒng)要切換 B 作為主庫。我們在主動切換的時候，可以等到主備延遲小于 5 秒的時候再啟動切換，但這時候已經(jīng)別無選擇了。
采用可靠性優(yōu)先策略的話，你就必須得等到備庫 B 的 seconds_behind_master=0 之后，才能切換。但現(xiàn)在的情況比剛剛更嚴(yán)重，并不是系統(tǒng)只讀、不可寫的問題了，而是系統(tǒng)處于完全不可用的狀態(tài)。因為，主庫 A 掉電后，我們的連接還沒有切到備庫 B。
那能不能直接切換到備庫 B，但是保持 B 只讀呢？
這樣也不行。因為，這段時間內(nèi)，中轉(zhuǎn)日志還沒有應(yīng)用完成，如果直接發(fā)起主備切換，客戶端查詢看不到之前執(zhí)行完成的事務(wù)，會認(rèn)為有“數(shù)據(jù)丟失”。雖然隨著中轉(zhuǎn)日志的繼續(xù)應(yīng)用，這些數(shù)據(jù)會恢復(fù)回來，但是對于一些業(yè)務(wù)來說，查詢到“暫時丟失數(shù)據(jù)的狀態(tài)”也是不能被接受的。
總結(jié)
今天介紹了，什么是主從延遲，主從延遲的五大來源，通過舉例介紹了什么是可靠性優(yōu)先策略，可用性優(yōu)先策略?？捎眯詢?yōu)先策略的性能是大于可靠性優(yōu)先策略的。但是可靠性優(yōu)先策略的安全性一致性大于可用性優(yōu)先策略。
剩下的就是根據(jù)自己的業(yè)務(wù)需求，自己抉擇啦。通過本篇學(xué)習(xí)你是否掌握了如何減少主從延遲以及高可用手法呢？