適用於 MySQL 的 Azure 資料庫彈性伺服器可讓您設定具有自動容錯移轉的高可用性。 此解決方案可確保失敗永遠不會導致認可的資料遺失，而且資料庫不會是軟體結構中的單一失敗點。 當您設定高可用性時，彈性伺服器會自動佈建及管理待命複本。 您需要支付主要與次要複本的已佈建計算與儲存體費用。 有兩個高可用性結構模型可供使用：
區域備援高可用性。 此選項提供跨多個可用性區域的完整基礎結構隔離與備援。 其提供最高層級的可用性，但您需要設定跨區域的應用程式備援。 當您想要防止可用性區域中的任何基礎結構失敗，以及跨可用性區域的延遲可接受時，請選擇區域備援 HA。 只有在建立伺服器時，才能啟用區域備援 HA。 Azure 區域子集中提供區域備援 HA，其中區域支援多個可用性區域，並且提供區域備援進階檔案共用。
本機備援高可用性。 此選項提供具有較低網路延遲的基礎結構備援，因為主要與待命伺服器位於相同的可用性區域中。 其提供高可用性，但不需要設定跨區域的應用程式備援。 當您想要在單一可用區域內以最低的網路延遲達到最高層級的可用性時，請選擇 Local-redundant HA。 您可以在所有 Azure 區域中使用本地備援 HA，您可以在這些區域中使用適用於 MySQL 的 Azure 資料庫彈性伺服器。
區域備援高可用性 (HA) 結構
當您部署具有區域備援高可用性的伺服器時，Azure 會建立兩部伺服器：
- 主要伺服器建立在某個可用性區域中。
- 相同 Azure 區域另一個可用性區域中的待命複本伺服器。 待命複本伺服器的設定與主要伺服器相同，包括計算服務層級、計算大小、儲存體大小，以及網路設定。
您可以同時為主要伺服器與待命複本選擇可用性區域。 將待命資料庫伺服器和待命應用程式放在相同的區域中，可以減少延遲。 其也可協助您為災害復原情況與「區域關閉」案例做好準備。
資料和記錄檔裝載於區域備援儲存體 (ZRS) 中。 待命伺服器會持續從主要伺服器的儲存體帳戶讀取並重新執行記錄檔，該帳戶受到儲存體層級複寫的保護。
容錯移轉發生時：
- 待命複本會啟用。
- 主要伺服器的二進位記錄檔會繼續套用至待命伺服器，使其上線至主要伺服器上的最後一筆已認可交易。
即使主要伺服器無法使用，仍然可以存取 ZRS 中的記錄。 此可用性有助於確保不會遺失資料。 啟用待命複本並套用二進位記錄之後，目前待命複本伺服器會扮演主要伺服器的角色。 DNS 會更新，因此會在用戶端重新連線時，將用戶端連線導向至新的主要伺服器。 來自用戶端應用程式的容錯移轉完全透明，而且不需要您採取任何動作。 HA 解決方案接著會在可能時帶回舊的主要伺服器，並將其放置為待命伺服器。
您可以使用資料庫伺服器名稱將應用程式連線至主要伺服器。 該解決方案不會公開待命複本資訊以供直接存取。 在主要伺服器的 ZRS 上排清記錄檔之後，會確認認可和寫入。 因為 ZRS 儲存體中使用同步複寫技術，所以您可以預期應用程式寫入和認可延遲會增加 5-10%。
自動備份 (快照集和記錄備份) 是在主要資料庫伺服器的區域備援儲存體上執行。
本地冗餘高可用性 (HA) 架構
當您部署具有本機備援 HA 的伺服器時，您會在相同的區域中建立兩部伺服器：
- 主要伺服器
- 設定 (計算層、計算大小、儲存體大小和網路設定) 與主要伺服器相同的待命複本伺服器
待命伺服器提供具有個別虛擬機器的基礎結構備援 (計算)。 因為共置，所以此備援可減少應用程式與資料庫伺服器之間的容錯移轉時間和網路延遲。
資料和記錄檔裝載於本機備援儲存體 (LRS) 中。 待命伺服器會持續從主要伺服器的儲存體帳戶讀取並重新執行記錄檔，該帳戶受到儲存體層級複寫的保護。
容錯移轉發生時：
- 待命複本會啟用。
- 主要伺服器的二進位記錄檔會繼續套用至待命伺服器，使其上線至主要伺服器上的最後一筆已認可交易。
即使主要伺服器無法使用，仍然可以存取 LRS 中的記錄。 此可用性有助於確保不會遺失資料。 啟動待命複本並套用二進位記錄之後，目前待命複本會扮演主要伺服器的角色。 DNS 已更新，以在用戶端重新連線時，將連線重新導向至新的主要資料庫。 來自用戶端應用程式的容錯移轉完全透明，而且不需要您採取任何動作。 HA 解決方案接著會在可能時帶回舊的主要伺服器，並將其放置為待命伺服器。
資料庫伺服器名稱會將應用程式連線至主要伺服器。 待命複本資訊不會公開以供直接存取。 在主要伺服器的 LRS 上排清記錄檔之後，會確認認可和寫入。 因為主要和待命複本位於相同的區域中，所以應用程式伺服器與資料庫伺服器之間的複寫延遲和延遲較低。 當特定可用性區域的相依基礎結構發生故障時，區域備援設置無法確保高可用性。 除非該可用性區域的所有相依服務都重新上線，否則會停機。
自動備份 (快照集和記錄備份) 是在主要資料庫伺服器的本機備援儲存體上執行。
附註
針對區域備援和本地備援 HA：
- 如果發生失敗，則待命複本接管主要複本角色所需的時間，取決於從主要複本儲存體帳戶重新執行二進位記錄到待命複本所需的時間。 若要減少容錯移轉時間，請在所有資料表上使用主索引鍵。 容錯移轉時間通常需要 60 到 120 秒。
- 待命伺服器不適用於讀取或寫入作業。 這是啟用快速容錯移轉的被動待命。
- 請一律使用完整網域名稱 (FQDN) 以連線至主要伺服器。 避免使用 IP 位址進行連線。 如果發生容錯移轉，則在切換主要與待命伺服器角色之後，DNS A 記錄可能會變更。 如果連接字串中使用 IP 位址，則該變更會防止應用程式連線至新的主要伺服器。
容錯移轉程序
在適用於 MySQL 的 Azure 資料庫中的容錯移轉流程期間，系統會自動從主要伺服器切換至待命複本。 此切換可確保持續性並將停機時間降到最低。 當系統偵測到失敗時，它會將待命複本升級為新的主要伺服器。 系統會將原始主要伺服器的二進位記錄檔套用至待命複本。 此流程會將待命複本與最後一筆已認可交易同步，並確保不會遺失資料。 這種無縫轉換有助於維護資料庫服務的高可用性與可靠性。
附註
為了減少容錯移轉時間對 DNS 快取的依賴，從 2025 年 10 月開始，所有使用公共存取或私人連結建立的新 HA 伺服器都將採用新架構，每個 HA 伺服器都有專用的 SLB。 透過管理 MySQL 資料流量路徑，SLB 消除了容錯移轉期間 DNS 變更的需求，並顯著提高了容錯移轉效能。 它會在容錯移轉期間使用負載平衡規則將流量重新導向至目前的主要執行個體。 具有公用存取或私人連結的現有伺服器將逐步移轉，以將影響降到最低。 偏好早期移轉的客戶可以停用並重新啟用 HA。 使用私人存取與 VNet 整合的伺服器不支援此功能。
計劃性：強制容錯移轉
適用於 MySQL 的 Azure 資料庫彈性伺服器強制容錯移轉可讓您手動強制執行容錯移轉。 此功能可讓您使用應用程式案例來測試功能，並協助您為中斷做好準備。
強制容錯移轉會觸發容錯移轉，藉由更新 DNS 記錄來啟動待命複本，使其成為具有相同資料庫伺服器名稱的主要伺服器。 原始主要伺服器會重新啟動，並切換到待命複本。 用戶端連線會中斷連線，而且需要重新連線才能恢復其作業。
整體的容錯移轉時間取決於目前的工作負載和最後一個檢查點。 一般而言，需要 60 到 120 秒。
附註
Azure 資源健康狀態事件會在計劃的容錯移轉期間產生。 該事件代表伺服器無法使用的容錯移轉時間。 選取左窗格中的 [資源健康狀態] 時，可以看到觸發的事件。 該狀態代表使用者起始或手動容錯移轉為「無法使用」，且已標記為「計劃的」。 範例 - 「授權使用者觸發了容錯移轉作業 (計劃性)」。 如果您的資源長時間保持此狀態，請建立支援票證，我們會協助您。
非計劃性：自動容錯移轉
由於軟體錯誤 (Bug) 或基礎結構錯誤 (例如計算、網路或儲存體失敗)，可能會發生非計劃性服務停機。 停電也會影響資料庫的可用性。 如果資料庫變得無法使用，則複寫到待命複本的作業會停止，而且待命複本會成為主要資料庫。 DNS 會更新，而且用戶端會重新連線至資料庫伺服器，以繼續其作業。
整體容錯移轉時間通常在 60 到 120 秒之間。 不過，視容錯移轉時主要資料庫伺服器中的活動而定 (例如大型交易與復原時間)，容錯移轉可能需要較長的時間。
附註
Azure 資源健康狀態事件會在非計劃性容錯移轉期間產生。 該事件代表伺服器無法使用時的容錯移轉時間。 當您在左窗格中選取 [資源健康狀態] 時，可以看到觸發的事件。 自動容錯移轉會顯示「無法使用」的狀態，並標示為「非計劃性」。
例如，無法使用：已自動觸發容錯移轉作業 (非計劃性)。 如果您的資源長時間處於此狀態，請建立支援票證，我們會協助您。
啟用 HA 的伺服器中的自動容錯移轉偵測運作方式
主要伺服器與次要伺服器各有兩個網路端點：
- 客戶端點：客戶會使用此端點連線並在執行個體上執行查詢。
- 管理端點：用於內部的服務通訊，以管理元件並連接到後端儲存體。
狀況監控元件會持續執行下列檢查：
- 監視器會對節點的管理網路端點執行 ping。 若此檢查連續失敗兩次，則會觸發自動容錯移轉作業。 此健康情況檢查可解決因作業系統問題而導致節點無法使用或無回應、管理元件與節點之間的網路問題以及類似問題等案例。
- 監視器會在執行個體上執行簡單查詢。 如果查詢無法執行，則會觸發自動容錯移轉。 此健康情況檢查可解決 MySQL 精靈損毀、停止或當機，以及後端儲存體問題與類似問題等案例。
附註
健康情況檢查不會監視應用程式與客戶網路端點 (私人/公用存取) 之間的網路問題。 這些問題可能發生在網路路徑中、端點上或用戶端上的 DNS 問題中。 如果您使用私人存取，請確定虛擬網路的 NSG 規則不會封鎖與連接埠 3306 上執行個體客戶網路端點的通訊。 針對公用存取，請確定已設定防火牆規則，且已在連接埠 3306 上允許網路流量 (如果網路路徑有任何其他防火牆)。 您還需要從用戶端應用程式端處理 DNS 解析。
監視高可用性
若要檢查伺服器的高可用性設定狀態，請在入口網站中使用伺服器 [高可用性] 窗格中的 [高可用性狀態]。
| 狀態 | 說明 |
|---|---|
| NotEnabled | 未啟用高可用性。 |
| ReplicatingData | 待命伺服器會在高可用性伺服器佈建期間或當您啟用高可用性選項時與主要伺服器同步。 |
| FailingOver | 資料庫伺服器正在從主要伺服器容錯移轉至待命伺服器。 |
| 良好 | 高可用性選項已啟用。 |
| 取消待機 | 當您停用高可用性選項時，刪除流程正在進行中。 |
若要監視高可用性伺服器的健康情況，請使用下列計量。
| 計量顯示名稱 | 計量 | 單位 | 描述 |
|---|---|---|---|
HA IO 狀態 |
ha_io_running | 狀態 | HA IO 狀態會顯示 HA 複寫的狀態。 如果 I/O 執行緒正在執行，則計量值為 1，否則為 0。 |
| HA SQL 狀態 | ha_sql_running | 狀態 | HA SQL 狀態會顯示 HA 複寫的狀態。 如果 SQL 執行緒正在執行，則計量值為 1，否則為 0。 |
| HA 複寫延遲 | 複製延遲 | 秒 | 複寫延遲是待命在重新執行從主要伺服器收到的交易時所落後的秒數。 |
限制
使用高可用性時，請記住下列考量：
您只能在建立伺服器期間設定區域備援高可用性。
可高載計算服務層級不支援高可用性。
重新啟動主要資料庫伺服器以套用靜態參數變更也會重新啟動待命複本。
該解決方案會開啟 GTID 模式，因為它使用 GTID。 檢查您的工作負載是否有 GTID 的複寫限制。
附註
預設會針對已進行高可用性設定的伺服器啟用儲存體自動成長，而且無法停用。
健康情況檢查
當您為適用於 MySQL 的 Azure 資料庫設定高可用性 (HA) 時，健康情況檢查在維護資料庫的可靠性與效能方面扮演著至關重要的角色。 這些檢查會持續監視主要與待命複本的狀態與健康情況，進而確保它們會立即偵測到任何問題。 透過追蹤各種計量 (例如伺服器回應能力、複寫延遲與資源使用率)，健康情況檢查有助於確保容錯移轉流程能夠順暢地執行，進而將停機時間降到最低並防止資料遺失。 正確設定的健康情況檢查對於在資料庫設定中達到所需可用性和復原層級而言非常重要。
監視健康情況
您可以透過 Azure 入口網站監視 HA 設定的健康情況。 要觀察的主要計量包括：
- 伺服器回應能力：指出主要伺服器是否可連線。
- 複寫延遲：測量主要複本與待命複本之間的延遲，確保資料一致性。
- 資源使用率：監視 CPU、記憶體與儲存體使用狀況以防止瓶頸。