MySQL怎麼保證高可用

主備延遲

即“同步延遲”。與資料同步有關的時間點主要包括以下三個：

1. 主庫 A 執行完成一個事務，寫入 binlog，我們把這個時刻記為 T1;
2. 之後傳給備庫 B，我們把備庫 B 接收完這個 binlog 的時刻記為 T2;
3. 備庫 B 執行完成這個事務，我們把這個時刻記為 T3。

所謂主備延遲，就是同一個事務，在備庫執行完成的時間和主庫執行完成的時間之間的差值，也就是 T3-T1。

你可以在備庫上執行 show slave status 命令，它的返回結果裡面會顯示 seconds_behind_master，用於表示當前備庫延遲了多少秒。

主備延遲的來源

首先，有些部署條件下，備庫所在機器的效能要比主庫所在的機器效能差。

解決：備庫使用和主庫同樣配置的資料庫

第二種常見的可能了，即備庫的壓力大

一般可以這麼處理：

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

第三種可能，即大事務。

不要一次性地用 delete 語句刪除太多資料。其實，這就是一個典型的大事務場景。

另一種典型的大事務場景，就是大表 DDL。

處理方案就是，計劃內的 DDL，建議使用 gh-ost 方案

主備切換的策略

1. 可靠性優先策略
2. 可用性優先策略

可靠性優先策略：

1. 判斷備庫 B 現在的 seconds_behind_master，如果小於某個值（比如 5 秒）繼續下一步，否則持續重試這一步；
2. 把主庫 A 改成只讀狀態，即把 readonly 設定為 true；
3. 判斷備庫 B 的 seconds_behind_master 的值，直到這個值變成 0 為止；
4. 把備庫 B 改成可讀寫狀態，也就是把 readonly 設定為 false；
5. 把業務請求切到備庫 B。

在滿足資料可靠性的前提下，MySQL 高可用系統的可用性，是依賴於主備延遲的。延遲的時間越小，在主庫故障的時候，服務恢復需要的時間就越短，可用性就越高。