MySQL高可用原理

在一個(gè)主備關(guān)系中，每個(gè)備庫(kù)接收主庫(kù)的binlog并執(zhí)行。

正常情況下，只要主庫(kù)執(zhí)行更新生成的所有binlog，都可以傳到備庫(kù)并被正確執(zhí)行，備庫(kù)就能達(dá)到跟主庫(kù)一致的狀態(tài)，這就是最終一致性。

但Mysql要提供高可用能力，只有最終一致性還不夠。為什么呢？

Mysql主備切換流程–雙M結(jié)構(gòu)

主備延遲

主備切換可能是：

主動(dòng)運(yùn)維動(dòng)作

比如軟件升級(jí)、主庫(kù)所在機(jī)器按計(jì)劃下線等

被動(dòng)操作

比如主庫(kù)所在機(jī)器掉電。

同步延遲

與數(shù)據(jù)同步有關(guān)的時(shí)間點(diǎn)主要包括以下三個(gè)：

主庫(kù)A執(zhí)行完成一個(gè)事務(wù)，寫(xiě)入binlog，該時(shí)刻記為t1

之后傳給備庫(kù)B，備庫(kù)B接收完該binlog的時(shí)刻記為t2

備庫(kù)B執(zhí)行完成該事務(wù)，該時(shí)刻記為t3

主備延遲，就是同一事務(wù)，在 備庫(kù)執(zhí)行完成的時(shí)間 和 主庫(kù)執(zhí)行完成的時(shí)間 之間的差值，即t3-t1。

可以在備庫(kù)執(zhí)行show slave status，它的返回結(jié)果會(huì)顯示SBM（簡(jiǎn)稱(chēng) SBM），表示當(dāng)前備庫(kù)延遲了多少s。

SBM 計(jì)算方法：

每個(gè)事務(wù)的binlog都有一個(gè)時(shí)間字段，以記錄主庫(kù)上寫(xiě)入的時(shí)間

備庫(kù)取出當(dāng)前正在執(zhí)行的事務(wù)的時(shí)間字段的值，計(jì)算它與當(dāng)前系統(tǒng)時(shí)間的差值，得到SBM。

其實(shí)SBM就是t3-t1。所以，可以用SBM作為主備延遲的值，這個(gè)值的時(shí)間精度是s。

若主備庫(kù)機(jī)器的系統(tǒng)時(shí)間設(shè)置不一致，不會(huì)導(dǎo)致主備延遲的值不準(zhǔn)嗎？

不會(huì)的。因?yàn)椋瑐鋷?kù)連接到主庫(kù)時(shí)，會(huì)通過(guò)執(zhí)行SELECT UNIX_TIMESTAMP()函數(shù)獲得當(dāng)前主庫(kù)系統(tǒng)時(shí)間。若此時(shí)發(fā)現(xiàn)主庫(kù)系統(tǒng)時(shí)間與自己不一致，備庫(kù)在執(zhí)行SBM計(jì)算時(shí)，會(huì)自動(dòng)扣掉該差值。

在網(wǎng)絡(luò)正常時(shí)，日志從主庫(kù)傳給備庫(kù)所需時(shí)間很短，即t2-t1非常小。即網(wǎng)絡(luò)正常情況下，主備延遲的主要來(lái)源是備庫(kù)接收完binlog和執(zhí)行完該事務(wù)之間的時(shí)間差。

所以主備延遲最直接的表現(xiàn)是，備庫(kù)消費(fèi)中轉(zhuǎn)日志（relay log）的速度，比主庫(kù)生產(chǎn)binlog的速度要慢。這可能是由哪些原因?qū)е碌哪兀?/p>

主備延遲的來(lái)源

備庫(kù)所在機(jī)器的性能 < 主庫(kù)所在的機(jī)器性能

部署的人會(huì)想，反正備庫(kù)沒(méi)有請(qǐng)求，所以可以用差點(diǎn)兒的機(jī)器。或把20個(gè)主庫(kù)放在4臺(tái)機(jī)器，而把備庫(kù)集中在一臺(tái)機(jī)器。

但更新請(qǐng)求對(duì)IOPS的壓力，在主庫(kù)和備庫(kù)上是無(wú)差別的。所以，做這種部署時(shí)，一般都會(huì)將備庫(kù)設(shè)置為“非雙1”模式。

但實(shí)際上，更新過(guò)程中也會(huì)觸發(fā)大量讀操作。所以，當(dāng)備庫(kù)主機(jī)上的多個(gè)備庫(kù)都在爭(zhēng)搶資源時(shí)，就可能導(dǎo)致主備延遲。

這種部署現(xiàn)在少了。因?yàn)橹鱾淇赡馨l(fā)生切換，備庫(kù)隨時(shí)可能變成主庫(kù)，所以主備庫(kù)必須選用相同規(guī)格機(jī)器，并且做對(duì)稱(chēng)部署。

我們也做了對(duì)稱(chēng)部署，但還有延遲，為啥？

很可能備庫(kù)的壓力大。主庫(kù)既然提供了寫(xiě)能力，那么備庫(kù)可以提供一些讀能力。或一些運(yùn)營(yíng)后臺(tái)需要的分析語(yǔ)句，不能影響正常業(yè)務(wù)，所以只能在備庫(kù)上跑。

由于主庫(kù)直接影響業(yè)務(wù)，大家使用起來(lái)會(huì)比較克制，反而忽視了備庫(kù)的壓力控制。結(jié)果備庫(kù)上的查詢(xún)耗費(fèi)大量CPU，影響同步速度 =》主備延遲。

這時(shí)一般可以這么處理：

一主多從

除了備庫(kù)外，可以多接幾個(gè)從庫(kù)，讓這些從庫(kù)來(lái)分擔(dān)讀壓力。大多采用該方案，因?yàn)閿?shù)據(jù)庫(kù)系統(tǒng)必須保證有定期全量備份能力。而從庫(kù)，很適合用來(lái)做備份。

通過(guò)binlog輸出到外部系統(tǒng)

比如Hadoop，讓外部系統(tǒng)提供統(tǒng)計(jì)類(lèi)查詢(xún)的能力。

從庫(kù)和備庫(kù)在概念上其實(shí)差不多。一般把會(huì)在HA過(guò)程中被選成新主庫(kù)的，稱(chēng)為備庫(kù)，其他的稱(chēng)為從庫(kù)。

我們也采用了一主多從，保證備庫(kù)壓力不會(huì)超過(guò)主庫(kù)，但還主備延遲，為啥？

可能就是大事務(wù)了。因?yàn)樵谥鲙?kù)，必須等事務(wù)執(zhí)行完成才會(huì)寫(xiě)binlog，再傳給備庫(kù)。所以，若一個(gè)主庫(kù)的語(yǔ)句執(zhí)行10min，則該事務(wù)可能就會(huì)導(dǎo)致從庫(kù)延遲10min。

比如，一些歸檔類(lèi)數(shù)據(jù)，平時(shí)沒(méi)有注意刪除歷史數(shù)據(jù)，等空間快滿(mǎn)，SE要一次性刪大量歷史數(shù)據(jù)。又要避免在高峰期，所以會(huì)在晚上執(zhí)行這些大量數(shù)據(jù)刪除。

結(jié)果，DBA半夜收到延遲報(bào)警。然后，DBA要求你后續(xù)再刪數(shù)據(jù)時(shí)，要控制每個(gè)事務(wù)刪除的數(shù)據(jù)量，分成多次刪除。

計(jì)劃內(nèi)的DDL，建議使用gh-ost方案

我們主庫(kù)也沒(méi)大事務(wù)，怎么還主備延遲？

可能因?yàn)閭鋷?kù)的并行復(fù)制能力。

其他情況

TODO。

由于主備延遲的存在，所以在主備切換時(shí)，就有不同

策略

可靠性?xún)?yōu)先策略

比如一開(kāi)始的雙M架構(gòu)，切換過(guò)程如下：

判斷備庫(kù)B現(xiàn)在的SBM，若小于某值（比如5s）繼續(xù)下一步，否則持續(xù)重試該步

把主庫(kù)A改成只讀狀態(tài)，即把readonly設(shè)置為true

判斷備庫(kù)B的SBM值，直到該值=0

把備庫(kù)B改成可讀寫(xiě)狀態(tài)：把readonly 設(shè)置為false

把業(yè)務(wù)請(qǐng)求切到備庫(kù)B

切換一般由HA系統(tǒng)完成。

MySQL可靠性?xún)?yōu)先主備切換流程

該切換流程中有不可用時(shí)間。因?yàn)樵趕tep2后，A、B都readonly，此時(shí)系統(tǒng)不可寫(xiě)，直到step5完成后才恢復(fù)。

在這個(gè)不可用過(guò)程，較耗時(shí)的是step3，可能耗費(fèi)幾s。這也是為什么要在step1先做判斷，確保SBM足夠小。

倘若一開(kāi)始主備延遲就長(zhǎng)如30min，而不先做判斷直接切換，系統(tǒng)的不可用時(shí)間就會(huì)長(zhǎng)達(dá)30min，一般業(yè)務(wù)都是不能接受的。

系統(tǒng)的不可用時(shí)間，是由該數(shù)據(jù)可靠性?xún)?yōu)先的策略決定的。也可選擇可用性?xún)?yōu)先的策略，來(lái)把這個(gè)不可用時(shí)間幾乎降為0。

可用性?xún)?yōu)先策略

如果我強(qiáng)行把步驟4、5調(diào)整到最開(kāi)始執(zhí)行，也就是說(shuō)不等主備數(shù)據(jù)同步，直接把連接切到備庫(kù)B，并且讓備庫(kù)B可以讀寫(xiě)，那么系統(tǒng)幾乎就沒(méi)有不可用時(shí)間了。

我們把這個(gè)切換流程，暫時(shí)稱(chēng)作可用性?xún)?yōu)先流程。這個(gè)切換流程的代價(jià)，就是可能出現(xiàn)數(shù)據(jù)不一致的情況。

接下來(lái)，我就和你分享一個(gè)可用性?xún)?yōu)先流程產(chǎn)生數(shù)據(jù)不一致的例子。假設(shè)有一個(gè)表 t：

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);

初始化數(shù)據(jù)后，主庫(kù)和備庫(kù)上都是3行數(shù)據(jù)。接下來(lái)，業(yè)務(wù)人員要繼續(xù)在表t上執(zhí)行兩條插入語(yǔ)句的命令，依次是：

insert into t(c) values(4); insert into t(c) values(5);

假設(shè)，現(xiàn)在主庫(kù)上其他的數(shù)據(jù)表有大量更新，導(dǎo)致主備延遲達(dá)到5s。在插入一條c=4的語(yǔ)句后，發(fā)起了主備切換。

可用性?xún)?yōu)先策略，且binlog_format=mixed時(shí)的切換流程和數(shù)據(jù)結(jié)果。

step2：主庫(kù)A執(zhí)行完insert，插入了一行數(shù)據(jù)（4,4），之后開(kāi)始進(jìn)行主備切換

step3：由于主備之間5s延遲，所以備庫(kù)B還沒(méi)來(lái)得及應(yīng)用“插入c=4”這個(gè)中轉(zhuǎn)日志，就開(kāi)始接收客戶(hù)端“插入 c=5”的命令

step4：備庫(kù)B插入數(shù)據(jù)（4,5），并把該binlog發(fā)給主庫(kù)A

step5：備庫(kù)B執(zhí)行“插入c=4”這個(gè)中轉(zhuǎn)日志，插入一行數(shù)據(jù)（5,4）。而直接在備庫(kù)B執(zhí)行的“插入c=5”這個(gè)語(yǔ)句，傳到主庫(kù)A，就插入一行新數(shù)據(jù)（5,5）。

最終，A、B上出現(xiàn)兩行不一致數(shù)據(jù)，是由可用性?xún)?yōu)先流程導(dǎo)致。

若我還是想用可用性?xún)?yōu)先策略，但設(shè)置binlog_format=row，會(huì)咋樣？

row格式在記錄binlog時(shí)，會(huì)記錄新插入的行的所有字段值，所以最后只會(huì)有一行不一致。而且兩邊主備同步的應(yīng)用線程會(huì)報(bào)錯(cuò)duplicate key error并停止。即這種情況，B的(5,4)和A的(5,5)這兩行數(shù)據(jù)，都不會(huì)被對(duì)方執(zhí)行：

可用性?xún)?yōu)先策略，且binlog_format=row

所以使用row格式，數(shù)據(jù)不一致更容易被發(fā)現(xiàn)。而使用mixed、statement，數(shù)據(jù)很可能悄悄地就不一致。若你過(guò)很久才發(fā)現(xiàn)數(shù)據(jù)不一致，那可能只能刪庫(kù)跑路了。

主備切換的可用性?xún)?yōu)先策略會(huì)導(dǎo)致數(shù)據(jù)不一致。所以更推薦使用可靠性?xún)?yōu)先策略。畢竟對(duì)數(shù)據(jù)服務(wù)，數(shù)據(jù)的可靠性 > 可用性。

有沒(méi)有哪種情況數(shù)據(jù)的可用性?xún)?yōu)先級(jí)就是更高呢？

有個(gè)庫(kù)的作用是記錄操作日志。這時(shí)，若數(shù)據(jù)不一致，可通過(guò)binlog修復(fù)，而這短暫不一致也不會(huì)引發(fā)業(yè)務(wù)問(wèn)題。

同時(shí)，業(yè)務(wù)系統(tǒng)依賴(lài)于這個(gè)日志的寫(xiě)入邏輯，若該庫(kù)不可寫(xiě)，會(huì)導(dǎo)致線上業(yè)務(wù)操作無(wú)法執(zhí)行。

這時(shí)候，你可能需要先強(qiáng)行切換，事后再補(bǔ)數(shù)據(jù)。

事后復(fù)盤(pán)，想到個(gè)改進(jìn)措施：讓業(yè)務(wù)邏輯不要依賴(lài)于這類(lèi)日志的寫(xiě)入。即日志寫(xiě)入這個(gè)邏輯模塊應(yīng)該可降級(jí)，比如寫(xiě)到本地文件或另外一個(gè)臨時(shí)庫(kù)。

這種場(chǎng)景就可以使用可靠性?xún)?yōu)先策略了。

按可靠性?xún)?yōu)先，異常切換會(huì)是什么效果？

假設(shè)，主庫(kù)A和備庫(kù)B間的主備延遲是30min，這時(shí)主庫(kù)A掉電，HA系統(tǒng)要切換B作為主庫(kù)。在主動(dòng)切換時(shí)，可以等到主備延遲小于5s時(shí)，再啟動(dòng)切換，但這時(shí)已經(jīng)別無(wú)選擇了。

可靠性?xún)?yōu)先策略，主庫(kù)不可用

采用可靠性?xún)?yōu)先策略，必須得等到備庫(kù)B的SBM=0后，才能切換。但現(xiàn)在比剛剛更嚴(yán)重，并不是系統(tǒng)只讀、不可寫(xiě)，而是系統(tǒng)處于完全不可用。因?yàn)椋鲙?kù)A掉電后，我們的連接還沒(méi)有切到備庫(kù)B。

能否直接切換到備庫(kù)B，但保持B只讀？

不行。因?yàn)椋@段時(shí)間內(nèi)，中轉(zhuǎn)日志還沒(méi)有應(yīng)用完成，若直接發(fā)起主備切換，客戶(hù)端查詢(xún)看不到之前執(zhí)行完成的事務(wù)，會(huì)認(rèn)為有“數(shù)據(jù)丟失”。

雖然隨著中轉(zhuǎn)日志的繼續(xù)應(yīng)用，這些數(shù)據(jù)會(huì)恢復(fù)回來(lái)，但對(duì)于一些業(yè)務(wù)，查詢(xún)到“暫時(shí)丟失數(shù)據(jù)的狀態(tài)”不能被接受。

在滿(mǎn)足數(shù)據(jù)可靠性的前提下，MySQL高可用系統(tǒng)的可用性，依賴(lài)于主備延遲。延遲越小，在主庫(kù)故障時(shí)，服務(wù)恢復(fù)需要時(shí)間越短，可用性越高。

MySQL 數(shù)據(jù)庫(kù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。