主備切換的原因, 影響和操作 - ApsaraDB for Redis

當ApsaraDB for Redis監測到執行個體的主節點不可用時，會自動觸發主備切換，將備節點提升為主節點，保障執行個體的高可用性。若您收到簡訊、郵件、控制台站內信等通知，告知您Redis執行個體已完成主備切換，您可以參考本文瞭解主備切換的原因、影響和處理建議等。

為什麼會觸發主備切換？

執行個體底層主機故障
阿里雲檢測到執行個體底層主機發生故障，例如進程異常中斷、執行個體負載過高導致記憶體異常等無法正常使用時，系統會立即觸發主備切換，及時恢複執行個體，降低故障影響時間長度。
此類觸發方式會以站內信、郵件等形式通知到您，通知樣本如下：
【阿里雲】尊敬的****：您的ApsaraDB for Redis執行個體：r-bp1zxszhcgatnx****（名稱：****）出現異常，高可用系統已經觸發切換，確保執行個體穩定運行。請檢查程式串連是否正常，建議設定自動重連機制以避免切換影響。
執行個體底層主機存在風險隱患
阿里雲檢測到執行個體底層主機存在風險時，例如網路抖動異常、磁碟異常等風險時，且此類風險可能會在未來影響執行個體的正常使用。系統會自動下發主動營運任務來處理此類風險項，並在可維護時間段觸發主備切換，替換掉存在風險的主機節點。
但緊急風險修複類事件通常會在第一時間修複並觸發主備切換，例如發現了Redis社區的嚴重Bug，執行個體會主動進行小版本升級。您可以在歷史事件中查詢到此類觸發方式的記錄，更多資訊請參見查詢歷史事件。您也可以管理待處理的主備切換事件，更多資訊請參見查看並管理計劃內事件。

執行個體會自動完成完整的切換流程，在切換完成後，執行個體將正常運行。

但在切換過程中，會出現以下情況：

執行切換的資料節點將出現秒級的串連閃斷，可能還會出現30秒內的唯讀狀態。
在執行個體處於切換中狀態時，將無法執行執行個體層級的操作（例如變更配置、遷移可用性區域等）。當執行個體完成主備切換後，執行個體狀態會顯示為運行中。

請提前為您的應用設計重連機制和異常處理的能力，否則業務應用可能在執行個體切換階段產生間歇性的異常資訊，例如：READONLY You can't write against a read only instance或DISABLE You can't write or read against a disable instance。
當執行個體觸發主備切換後，執行個體會自動完成完整的切換流程：將備節點提升為主節點，同時會建立新的備節點，進行主備節點資料同步。您無需進行任何操作。
說明
雙可用性區域執行個體在主備切換後，主節點位於備可用性區域、備節點位於主可用性區域。系統會在120分鐘內再次切換，自動將主節點切換至原主可用性區域，避免執行個體與其他業務產生跨機房訪問的情況。您無需進行任何操作。

Q：執行個體故障觸發主備切換的原理是什嗎？

A：依賴高可用HA（High Availability）系統的探活機制實現故障檢測，具體如下：

主要事件	說明
健康檢測	HA系統會探測確認主備節點健康狀態。
主節點異常	發現主節點不可用，會將備節點提升為主節點，同時將虛擬IP地址VIP（Virtual IP Address）切換至備節點，但不會變更執行個體串連地址。建立新的備節點並完成資料同步。
備節點異常	發現備節點不可用，HA系統將自動建立新的備節點並完成資料同步，保障主備雙副本架構的持久性。

說明

由於主備節點間的同步資料是非同步實現的，可能會丟失主節點最近寫入的部分資料。