什么時候是主備切換的最佳時機?

主從延遲越小越好。

如何查看備庫的同步延遲?

-- 在slave上執行以下命令
show slave status\G

上圖返回結果中包含一個seconds_behind_master字段，用于表示當前備庫延遲了多少秒。

seconds_behind_master的計算邏輯

• 每個事務的binlog里面都有一個時間字段，用于記錄主庫上的寫入時間
• 備庫取出當前正在執行的事務的時間字段的值，計算它與當前系統時間的差值，得到seconds_behind_master
• 備庫在連接到主庫時，會通過執行select unix_timestamp()函數獲取主庫的系統時間，如果發現主庫和自己的時間不一致，備庫在計算seconds_behind_master會自動扣掉這個差值

什么情況下會發生主備切換?

• 主動運維操作
• 主庫意外宕機

主備延遲的原因?

• 備庫機器配置較低
• 備庫壓力大(比如在備庫上執行一些占用資源的運營報表分析)
• 大事務
• 備庫的并行復制能力

主備切換策略由哪幾種?

• 可靠性優先策略
• 可用性優先策略

什么是可靠性優先策略?

可靠性優先策略優先保證數據的可靠性，通常由專門HA系統實現。

可靠性優先策略下的主備切換邏輯

1. 判斷Slave B現在的seconds_behind_master，如果小于某個值(比如5s)繼續下一步，否則重試這一步
2. 把Master A修改為只讀狀態
3. 判斷Slave B的seconds_behind_master的值，直到這個值變為0為之
4. 把Slave B改為可讀寫狀態
5. 把業務請求切到備庫B，此時Slave B就正式晉升為主庫

可靠性優先策略假設主從延遲很大，無法快速切換，主節點又不可用，這將會導致服務長時間的不可用。

可用性優先策略

可用性優先策略是不再等待主從同步完成，如果主節點一旦宕機，立馬進行切換，但是此時可能會導致數據一致性問題。

尤其是當binlog模式是statement或者mixed模式下的時候，很容易造成數據不一致。如果binlog模式是ROW模式，由于記錄的是某個行記錄的全字段，在插入數據的時候可能會因為主鍵沖突，使得同步線程報錯并停止。

在實際使用中，我更建議使用可靠性優先策略，畢竟對于數據服務來說，數據可靠性重要程度要高于可用性。