共用方式為

適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中的高可用性概念

  • 發行項

適用於 MySQL 的 Azure 資料庫彈性伺服器可讓您設定具有自動容錯移轉功能的高可用性。 高可用性解決方案旨在確保認可的資料絕不會因為失敗而遺失，以及資料庫將不會是您軟體架構中的單一失敗點。 設定高可用性時，彈性伺服器會自動佈建和管理待命複本。 系統會針對主要和次要複本的已佈建計算和儲存體進行計費。 有兩個高可用性架構模型：

  • 區域備援 HA。 此選項適用於跨多個可用性區域的完整基礎結構隔離和備援。 其提供最高層級的可用性，但您需要設定跨區域的應用程式備援。 如果您想要針對可用性區域中的任何基礎結構失敗達到最高層級的可用性，以及可接受可用性區域之間的延遲時，則偏好使用區域備援 HA。 只有在建立伺服器時，才能將其啟用。 Azure 區域子集中提供區域備援 HA，其中區域支援多個可用性區域，並且提供區域備援進階檔案共用。

  • 相同區域 HA。 因為主要和待命伺服器將位於相同的可用性區域中，所以此選項偏好用於網路延遲較低的基礎結構備援。 其提供高可用性，但不需要設定跨區域的應用程式備援。 當您想要在具有最低網路延遲的單一可用性區域內達到最高層級的可用性時，最好使用相同區域 HA。 所有可使用適用於 MySQL 的 Azure 資料庫彈性伺服器的 Azure 區域皆可使用相同的區域 HA。

區域備援 HA 架構

當您部署具有區域備援 HA 的伺服器時，將會建立兩部伺服器：

  • 主要伺服器建立在某個可用性區域中。
  • 與主要伺服器具有相同設定 (計算層、計算大小、儲存體大小和網路設定) 的待命複本伺服器則建立在相同 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 記錄來啟動待命複本，使其成為具有相同資料庫伺服器名稱的主要伺服器。 原始的主要伺服器會重新啟動，並切換到待命複本。 用戶端連線會中斷連線，而且需要重新連線才能繼續其作業。

整體的容錯移轉時間取決於目前的工作負載和最後一個檢查點。 一般情況下，預期會花 60 到 120 秒。

注意

發生計劃性容錯移轉時會產生 Azure 資源健康狀態事件，以表示伺服器無法使用的容錯移轉時間。 在左窗格中選取 [資源健康狀態] 時，可以看到觸發的事件。 使用者起始的/手動的容錯移轉會以「無法使用」的狀態來表示，並標記為「計劃性」。 範例 - 「授權使用者觸發了容錯移轉作業 (計劃性)」。 如果您的資源長時間處於此狀態，請開啟支援票證，我們便會為您提供協助。

非計劃性：自動容錯移轉

非計劃性服務停機可能會由軟體錯誤或基礎結構錯誤 (例如計算、網路或儲存體失敗)，或影響資料庫可用性的電源中斷造成。 如果資料庫變得無法使用，複寫到待命複本的作業會遭到中斷，而待命複本會啟用並成為主要資料庫。 DNS 已更新，而且用戶端會重新連線至資料庫伺服器，並繼續其作業。

整體容錯移轉時間預期會在 60 到 120 秒之間。 但是，根據容錯移轉時 (例如大型交易和復原時間) 主要資料庫伺服器中的活動，容錯移轉可能需要較長的時間。

注意

發生非計劃性容錯移轉時會產生 Azure 資源健康狀態事件，以表示伺服器無法使用的容錯移轉時間。 在左窗格中選取 [資源健康狀態] 時，可以看到觸發的事件。 自動容錯移轉會以「無法使用」的狀態來表示，並標記為「非計劃性」。 範例 - 「無法使用：已自動觸發容錯移轉作業 (非計劃性)」。 如果您的資源長時間處於此狀態，請開啟支援票證，我們便會為您提供協助。

啟用 HA 的伺服器中的自動容錯移轉偵測運作方式

主伺服器和次要伺服器有兩個網路端點。

  • 用戶端點：客戶會使用此端點來連線並執行實例上的查詢。
  • 管理端點：用於內部的服務通訊，以管理元件並連接到後端儲存體。

健康情況監視器元件會持續執行下列檢查

  • 監視器會偵測到節點管理網路端點。 若此檢查連續失敗兩次，則會觸發自動容錯移轉作業。 節點因作業系統問題、管理元件與節點之間的網路問題等情節無法使用/無法回應。此健康情況檢查會將其解決。
  • 監視器也會在「執行個體」上執行簡易查詢。 若無法執行查詢，將會觸發自動容錯移轉。 MySQL 會示範損毀/停止/無回應、後端儲存體問題等情節，此健康情況會將其解決。

注意

若應用程式和客戶網路端點之間發生任何網路問題 (私人/公用存取)，在用戶端的端點或 DNS 問題中，健康情況檢查不會監視此案例。 如果您使用私人存取，請確定 VNet 的 NSG 規則不會封鎖連接埠 3306 上執行個體客戶網路端點的通訊。 而公用存取，請確定已設定防火牆規則，並在連接埠 3306 上允許網路流量 (如果網路路徑有任何其他的防火牆)。 用戶端應用程式端的 DNS 解析也需處理。

監視高可用性

位於入口網站中伺服器 [高可用性] 窗格的 [高可用性狀態] 可用來判斷伺服器的 HA 組態狀態。

狀態 說明
NotEnabled 未啟用 HA。
ReplicatingData 待命伺服器是在 HA 伺服器佈建時或啟用 HA 選項時，與主要伺服器進行同步處理。
FailingOver 資料庫伺服器正在從主要伺服器容錯移轉至待命伺服器。
良好 已啟用 HA 選項。
RemovingStandby 停用 HA 選項，且正在進行刪除程序時。

您也可以使用下列計量來監視 HA 伺服器的健康情況。

計量顯示名稱 計量 單位 描述
HA IO 狀態 ha_io_running 州/省 HA IO 狀態會指出 HA 複寫的狀態。 如果 I/O 執行緒正在執行，則計量值為 1，如果未執行，則為 0。
HA SQL 狀態 ha_sql_running 州/省 HA SQL 狀態會指出 HA 複寫的狀態。 如果 SQL 執行緒正在執行，則計量值為 1，如果未執行，則為 0。
HA 複寫延遲。 replication_lag 秒 複寫延隔時間是指待命伺服器在重新執行從主要伺服器接收到的交易時所落後的秒數。

限制

以下是使用高可用性時要記住的一些考量：

  • 只有在建立彈性伺服器時，才能設定區域備援高可用性。
  • 可高載計算層不支援高可用性。
  • 重新啟動主要資料庫伺服器，以挑選靜態參數變更也會重新啟動待命複本。
  • HA 解決方案使用 GTID 時，將會開啟 GTID 模式。 檢查您的工作負載是否有 GTID 的複寫限制。

注意

如果您要在伺服器建立後啟用同一區域HA，您必須先確定伺服器參數enforce_gtid_consistency“和 ”gtid_mode“ 已設定為ON，再啟用HA。

注意

已設定高可用性伺服器的儲存體自動成長預設為啟用，因此無法停用。

常見問題集 (FAQ)

  • 已啟用區域與區域備援 HA 彈性伺服器的 SLA 為何？

    如需適用於 MySQL 的 Azure 資料庫彈性伺服器的 SLA 資訊，請參閱適用於 MySQL 的 Azure 資料庫的 SLA。

  • 如何針對高可用性 (HA) 伺服器計費？ 已啟用高可用性的伺服器會具有主要及次要複本。 次要複本可位於相同區域內，或位於區域備援中。 系統會針對主要和次要複本的已佈建計算和儲存體進行計費。 例如，若主要複本有 4 個 vCore 的計算及 512 GB 的已佈建儲存體，則次要複本也會有 4 個 vCore 及 512 GB 的已佈建儲存體。 您的區域備援 HA 伺服器將按 8 個 vCore 及 1024 GB 的儲存體計費。 視備份記憶體磁碟區而定，您也可能需支付備份記憶體的費用。

  • 我是否可以使用待命複本來進行讀取或寫入作業？
    待命伺服器不適用於讀取或寫入作業。 這是啟用快速容錯移轉的被動待命。

  • 發生容錯移轉時，是否將會遺失資料？
    即使主要伺服器無法使用，仍然可以存取 ZRS 中的記錄。 此可用性有助於確保不會遺失資料。 待命複本在啟動並套用二進位記錄之後，就會扮演主要伺服器的角色。

  • 我是否需要在容錯移轉之後採取任何動作？
    來自用戶端應用程式的容錯移轉完全透明。 您不需要採取任何動作。 應用程式應該只針對其連線使用重試邏輯。

  • 當我未針對待命複本選擇特定區域時，會發生什麼事？ 我是否可以稍後再變更區域？
    如果您未選擇區域，將會隨機選取一個區域。 其會是用於主要伺服器的某個區域。 若要稍後變更區域，您可以將 [高可用性] 窗格上的 [高可用性] 設定為 [已停用]，並將其設定回 [區域備援]，然後選擇區域。

  • 主要複本與待命複本之間的複寫是否同步？
    主要與待命之間的複寫類似於 MySQL 中的半同步模式。 認可交易時，不需要認可至待命。 但是，主要複本無法使用時，待命會複寫主要複本中的所有資料變更，以確保不會遺失資料。

  • 是否所有非計劃性失敗都會容錯移轉至待命複本？
    如果資料庫損毀或節點失敗，則會在相同的節點上重新啟動彈性伺服器 VM。 同時會觸發自動容錯移轉。 如果在容錯移轉完成之前成功重新啟動彈性伺服器 VM，則會取消容錯移轉作業。 決定要將哪部伺服器用作主要複本，取決於先完成的程序。

  • 當我使用 HA 時是否會影響效能？
    對於區域備援 HA，雖然跨可用性區域讀取工作負載沒有重大效能影響，但寫入查詢延遲可能會降低最多 40%。 寫入延遲增加的原因是跨可用性區域進行同步複寫。 相較於相同的區域 HA，寫入延遲影響通常會在區域備援 HA 中兩倍。 針對相同區域 HA，因為主要和待命複本位於相同區域，所以複寫延遲和同步寫入延遲較低。 總而言之，如果相較於可用性而言，寫入延遲對您來說更為重要，您可能會想要選擇相同的區域 HA，但如果數據的可用性和復原性對您而言更為重要，代價是寫入延遲下降，您必須選擇區域備援 HA。 若要測量 HA 設定中延遲下降的精確影響，建議您為工作負載執行效能測試，以做出明智的決策。

  • 如何維護 HA 伺服器？
    縮放計算和次要版本升級等計劃性事件會先在原始待命執行個體上發生，接著是觸發計劃性容錯移轉作業，然後在原始主要執行個體上運作。 您可以設定 HA 伺服器的排程維護時間範圍，就像針對彈性伺服器一樣。 停用 HA 時，停機時間長度會與適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體的停機時間相同。

  • 我可以執行 HA 伺服器的時間點還原 (PITR) 嗎？
    您可以將已啟用 HA 的適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體 PITR 至已停用 HA 的新適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體。 如果來源伺服器已使用區域備援 HA 所建立，則您稍後可以在已還原的伺服器上啟用區域備援 HA 或相同區域 HA。 如果來源伺服器已使用相同區域 HA 所建立，則您只能在已還原的伺服器上啟用相同區域 HA。

  • 我是否可以在建立伺服器之後於伺服器上啟用 HA？
    建立伺服器時，需要啟用區域備援 HA。 在您建立伺服器之後，可以啟用相同區域 HA。 啟用相同的區域 HA 之前，請確定伺服器參數enforce_gtid_consistency“ 和 「gtid_mode」 設定為 ON

  • 我是否可以在建立伺服器之後停用其 HA？
    您可以在建立伺服器之後停用其上的 HA。 計費會立即停止。

  • 如何減輕停機時間？
    即使您未使用 HA，還是需要可以減輕應用程式的停機時間。 服務停機時間，例如排程的修補程式、次要版本升級或客戶起始的作業 (例如在排程的維護時間範圍期間執行計算的調整)。 若要減輕 Azure 起始維護工作的應用程式影響，您可以排程在一周的某一天和某個時間執行這些工作，以將對應用程式的影響降到最低。

  • 我是否可以針對已啟用 HA 的伺服器使用讀取複本？
    是，HA 伺服器不支援讀取複本。

  • 我是否可以針對 HA 伺服器使用資料輸入複寫？
    只有在透過 GTID 型複寫時，才會為已啟用高可用性 (HA) 的伺服器支援資料輸入複寫。 使用 GTID 的複寫預存程序可透過 mysql.az_replication_with_gtid 名稱在所有已啟用 HA 的伺服器上使用。

  • 若要減少停機時間，我是否可以在伺服器重新開機期間或擴大或縮小時容錯移轉至待命伺服器？
    適用於 MySQL 的 Azure 資料庫彈性伺服器目前已使用計劃性容錯移轉將包括擴大/縮小在內的 HA 作業最佳化，並已使用計劃性維護來協助減少停機時間。 當這類作業啟動時，其會先在原始待命執行個體上運作，接著是觸發計劃性容錯移轉作業，然後在原始主要執行個體上運作。

  • 我們是否可以變更伺服器的可用性模式 (區域備援 HA/相同區域)
    如果您建立已啟用區域備援 HA 模式的伺服器，則可以從區域備援 HA 變更為相同區域，反之亦然。 若要變更可用性模式，您可以將 [高可用性] 窗格上的 [高可用性] 設定為 [已停用]，並將其設定回 [區域備援或相同區域]，然後選擇 [高可用性模式]。

相關內容