什么時候是主備切換的最佳時機?
主從延遲越小越好。
如何查看備庫的同步延遲?
-- 在slave上執行以下命令 show slave status\G
上圖返回結果中包含一個seconds_behind_master字段，用于表示當前備庫延遲了多少秒。
seconds_behind_master的計算邏輯
- 每個事務的binlog里面都有一個時間字段，用于記錄主庫上的寫入時間
- 備庫取出當前正在執行的事務的時間字段的值，計算它與當前系統時間的差值，得到seconds_behind_master
- 備庫在連接到主庫時，會通過執行select unix_timestamp()函數獲取主庫的系統時間，如果發現主庫和自己的時間不一致，備庫在計算seconds_behind_master會自動扣掉這個差值
什么情況下會發生主備切換?
- 主動運維操作
- 主庫意外宕機
主備延遲的原因?
- 備庫機器配置較低
- 備庫壓力大(比如在備庫上執行一些占用資源的運營報表分析)
- 大事務
- 備庫的并行復制能力
主備切換策略由哪幾種?
- 可靠性優先策略
- 可用性優先策略
什么是可靠性優先策略?
可靠性優先策略優先保證數據的可靠性，通常由專門HA系統實現。
可靠性優先策略下的主備切換邏輯
- 判斷Slave B現在的seconds_behind_master，如果小于某個值(比如5s)繼續下一步，否則重試這一步
- 把Master A修改為只讀狀態
- 判斷Slave B的seconds_behind_master的值，直到這個值變為0為之
- 把Slave B改為可讀寫狀態
- 把業務請求切到備庫B，此時Slave B就正式晉升為主庫
可靠性優先策略假設主從延遲很大，無法快速切換，主節點又不可用，這將會導致服務長時間的不可用。
可用性優先策略
可用性優先策略是不再等待主從同步完成，如果主節點一旦宕機，立馬進行切換，但是此時可能會導致數據一致性問題。
尤其是當binlog模式是statement或者mixed模式下的時候，很容易造成數據不一致。如果binlog模式是ROW模式，由于記錄的是某個行記錄的全字段，在插入數據的時候可能會因為主鍵沖突，使得同步線程報錯并停止。
在實際使用中，我更建議使用可靠性優先策略，畢竟對于數據服務來說，數據可靠性重要程度要高于可用性。
原文地址:https://www.toutiao.com/a7068928938910761483/
