目錄

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

主備切換

主備切換分為主動運維與被動操作。

軟件升級、主庫所在機器按計劃下線為主動運維。

主庫所在機器掉電為被動操作。

同步延遲

1、主庫A執行完一個事務，寫入binlog，時刻T1

2、傳給備庫B，備庫B接受完這個binlog，時刻T2；

3、備庫B執行完這個事務，時刻T3；

同一個事務，在備庫執行完成的時間和主庫執行完成的時間之差為T3-T1，又稱主備延遲。

在備庫執行show slave status命令會顯示seconds_behind_master，表示備庫延遲了多少秒。

主備庫機器系統時間設置不一樣并不會導致主備延遲的值不準。

在網絡正常的時候，日志從主庫傳給備庫的時間T2-T1是很短的。也就是說網絡正常時，主備延遲的主要來源是備庫接受完binlog和執行這個事務之間的時間差。

主備延遲最直接的表現就是：備庫消費中轉日志(relay log)的速度，比主庫生產binlog的速度慢。

主備延遲的原因

1、備庫所在機器的性能可能比主庫所在的機器性能差

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

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

這種情況可以這么解決：

1、一主多從。除了備庫外，可以多接幾個從庫，讓這些從庫來分擔讀的壓力2、通過binlog輸出到外部系統，讓外部系統提供統計查詢的能力

3、大事務情況

由于主庫必須等事務執行完才會寫入binlog，再傳給備庫。

如果一個主庫上的語句執行10分鐘，那么這個事務很可能會導致從庫延遲10分鐘。

典型大事務場景

a、一次性刪掉大量歷史數據。需要控制每個事務刪除的數據量，分成多次刪除

b、大表DDL

4、備庫并行復制能力差

可靠性優先策略的主備切換流程

在M-M結構下，狀態1切換到狀態2流程如下：

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

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

3、判斷備庫B的seconds_behind_master，直到這個值變為0

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

5、把業務請求切換到備庫B

step2之后，主庫A和備庫B都處于readonly狀態，此時系統處于不可寫狀態，直到step5才能恢復。step3比較耗時。

可用性優先策略的主備切換流程

如果強行把上面的step4、5調整到最開始執行，也就是說不等主備數據同步，直接把連接切到備庫B，并且讓備庫B可以讀寫，那么系統幾乎沒有不可用時間。

這個切換流程，稱為可用性優先流程，不過這個切換的代價，就是可能出現數據不一致的情況。

結論如下：

1、使用row格式的binlog時，數據不一致的問題更容易被發現。使用mixed或者statement格式的binlog時，數據很可能就不一致了。

2、主備切換的可用性優先策略會導致數據不一致，所以一般情況下使用可靠性優先策略。

下面介紹一個使用可用性優先策略的情形：

• 有一個庫的作用是記錄操作日志。如果數據不一致可以通過binlog來修補，而這個短暫的不一致也不會引發業務問題。

• 同時，業務系統依賴于這個日志寫入邏輯，如果這個庫不可寫，會導致線上的業務操作無法執行。

如果使用可靠性優先的思路，只能等待備庫慢慢應用中轉日志，在備庫應用完中轉日志且切換成讀寫狀態之前，數據庫是處于不可用的狀態。 這時也不能直接切換到備庫B，然后保持B庫只讀。

所以此時就需要用到可用性優先策略。

Mysql的高可用性，依賴于主備延遲。主備延遲的時間越小，出現故障的時候，服務需要恢復的時間就越短，可用性就越高