目錄

• • 主備切換
  • 主備延遲的原因
  • 可靠性優(yōu)先策略的主備切換流程
  • 可用性優(yōu)先策略的主備切換流程

主備切換

主備切換分為主動(dòng)運(yùn)維與被動(dòng)操作。

軟件升級(jí)、主庫所在機(jī)器按計(jì)劃下線為主動(dòng)運(yùn)維。

主庫所在機(jī)器掉電為被動(dòng)操作。

同步延遲

1、主庫A執(zhí)行完一個(gè)事務(wù)，寫入binlog，時(shí)刻T1

2、傳給備庫B，備庫B接受完這個(gè)binlog，時(shí)刻T2；

3、備庫B執(zhí)行完這個(gè)事務(wù)，時(shí)刻T3；

同一個(gè)事務(wù)，在備庫執(zhí)行完成的時(shí)間和主庫執(zhí)行完成的時(shí)間之差為T3-T1，又稱主備延遲。

在備庫執(zhí)行show slave status命令會(huì)顯示seconds_behind_master，表示備庫延遲了多少秒。

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

在網(wǎng)絡(luò)正常的時(shí)候，日志從主庫傳給備庫的時(shí)間T2-T1是很短的。也就是說網(wǎng)絡(luò)正常時(shí)，主備延遲的主要來源是備庫接受完binlog和執(zhí)行這個(gè)事務(wù)之間的時(shí)間差。

主備延遲最直接的表現(xiàn)就是：備庫消費(fèi)中轉(zhuǎn)日志(relay log)的速度，比主庫生產(chǎn)binlog的速度慢。

主備延遲的原因

1、備庫所在機(jī)器的性能可能比主庫所在的機(jī)器性能差

2、備庫壓力大。（主庫提供寫能力，備庫提供讀能力）

由于主庫直接影響業(yè)務(wù)，使用起來比較克制，反而忽視了備庫的壓力控制。結(jié)果就是，備庫上的查詢耗費(fèi)了大量的CPU資源，影響了同步速度，造成主備延遲。

這種情況可以這么解決：

1、一主多從。除了備庫外，可以多接幾個(gè)從庫，讓這些從庫來分擔(dān)讀的壓力2、通過binlog輸出到外部系統(tǒng)，讓外部系統(tǒng)提供統(tǒng)計(jì)查詢的能力

3、大事務(wù)情況

由于主庫必須等事務(wù)執(zhí)行完才會(huì)寫入binlog，再傳給備庫。

如果一個(gè)主庫上的語句執(zhí)行10分鐘，那么這個(gè)事務(wù)很可能會(huì)導(dǎo)致從庫延遲10分鐘。

典型大事務(wù)場景

a、一次性刪掉大量歷史數(shù)據(jù)。需要控制每個(gè)事務(wù)刪除的數(shù)據(jù)量，分成多次刪除

b、大表DDL

4、備庫并行復(fù)制能力差

可靠性優(yōu)先策略的主備切換流程

在M-M結(jié)構(gòu)下，狀態(tài)1切換到狀態(tài)2流程如下：

1、判斷備庫B現(xiàn)在的seconds_behind_master，如果小于某個(gè)值(比如5s)繼續(xù)下一步，否則繼續(xù)重試這一步

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

3、判斷備庫B的seconds_behind_master，直到這個(gè)值變?yōu)?

4、把備庫改成可讀寫狀態(tài)，(readonly設(shè)置為false)

5、把業(yè)務(wù)請求切換到備庫B

step2之后，主庫A和備庫B都處于readonly狀態(tài)，此時(shí)系統(tǒng)處于不可寫狀態(tài)，直到step5才能恢復(fù)。step3比較耗時(shí)。

可用性優(yōu)先策略的主備切換流程

如果強(qiáng)行把上面的step4、5調(diào)整到最開始執(zhí)行，也就是說不等主備數(shù)據(jù)同步，直接把連接切到備庫B，并且讓備庫B可以讀寫，那么系統(tǒng)幾乎沒有不可用時(shí)間。

這個(gè)切換流程，稱為可用性優(yōu)先流程，不過這個(gè)切換的代價(jià)，就是可能出現(xiàn)數(shù)據(jù)不一致的情況。

結(jié)論如下：

1、使用row格式的binlog時(shí)，數(shù)據(jù)不一致的問題更容易被發(fā)現(xiàn)。使用mixed或者statement格式的binlog時(shí)，數(shù)據(jù)很可能就不一致了。

2、主備切換的可用性優(yōu)先策略會(huì)導(dǎo)致數(shù)據(jù)不一致，所以一般情況下使用可靠性優(yōu)先策略。

下面介紹一個(gè)使用可用性優(yōu)先策略的情形：

• 有一個(gè)庫的作用是記錄操作日志。如果數(shù)據(jù)不一致可以通過binlog來修補(bǔ)，而這個(gè)短暫的不一致也不會(huì)引發(fā)業(yè)務(wù)問題。

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

如果使用可靠性優(yōu)先的思路，只能等待備庫慢慢應(yīng)用中轉(zhuǎn)日志，在備庫應(yīng)用完中轉(zhuǎn)日志且切換成讀寫狀態(tài)之前，數(shù)據(jù)庫是處于不可用的狀態(tài)。 這時(shí)也不能直接切換到備庫B，然后保持B庫只讀。

所以此時(shí)就需要用到可用性優(yōu)先策略。

Mysql的高可用性，依賴于主備延遲。主備延遲的時(shí)間越小，出現(xiàn)故障的時(shí)候，服務(wù)需要恢復(fù)的時(shí)間就越短，可用性就越高

總結(jié)

以上是生活随笔為你收集整理的《MySQL——主备切换流程与主备延迟》的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。