Azure SQL 受控執行個體 是一個完全託管的平台即服務（PaaS）資料庫引擎。 它提供近 100% 功能與 SQL Server 相容性。 Azure SQL 受控執行個體 負責大部分資料庫管理功能，如升級、修補、備份及監控，無需使用者參與。 它運行於最新穩定版本的 SQL Server 資料庫引擎，並搭配經過修補的作業系統，內建高可用性。
使用Azure時，可靠性是共同責任。 Microsoft 提供一系列功能來支援韌性和復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作，並選取符合業務目標和正常運作時間目標所需的功能。
本文說明如何讓 Azure SQL 受控執行個體 對各種潛在故障與問題具備韌性，包括暫時性故障、可用性區故障及區域故障。 同時說明如何利用備份來從其他類型的問題中復原，如何處理服務維護，並強調關於 Azure SQL 受控執行個體 服務水準協議（SLA）的一些重要資訊。
可靠性的生產部署建議
對於大多數 SQL 受管理執行個體 的生產部署，請考慮以下建議：
- 請遵循 高可用性和災害復原 （DR） 檢查清單中提供的指引。
- 啟用區域備援。
- 設定 自動備份，並使用區域備援儲存體 （ZRS） 或異地備援儲存體 （GRS） 進行備份。
- 計劃定期測試您的備份和還原程序。
可靠性架構概觀
通用 SQL 管理的實例運行在單一節點上，由 Azure Service Fabric 管理。 每當資料庫引擎或作業系統升級，或偵測到故障時，SQL 受管理執行個體 會與 Service Fabric 合作，將無狀態資料庫引擎程序移至另一個有足夠空餘容量的無狀態運算節點。 資料庫檔案儲存在 Azure Blob 儲存體 中，該軟體內建冗餘功能。 資料和記錄檔會從原始計算節點中斷連結，並連結至新初始化的資料庫引擎程序。
業務關鍵 SQL 受控執行個體會使用叢集中的多個複本。 叢集包含兩種類型的複本：
可供讀寫客戶端工作負載之用的單一主要複本
最多可以有五個包含資料副本的輔助副本（用於計算和儲存）
主要複本會持續且循序地將變更推送至次要複本，以確保資料在認可每個交易之前，會保存在足夠數量的次要複本上。 此程序可確保如果主要複本或可讀取的次要複本無法使用，則完全同步的複本一律可用於容錯移轉。
SQL 受管理執行個體 和 Service Fabric 會在複本間啟動故障轉移。 當次要複本成為新的主要複本後，就會建立另一個次要複本，以確保叢集有足夠的複本數量來維持仲裁。 故障轉移完成後，Azure SQL 連線會根據 連接字串 自動導向到新的主副本或可讀的次要副本。
Redundancy
預設情況下，SQL 受管理執行個體 透過將計算節點與資料分散於主要區域的單一資料中心來實現冗餘。 此方法可在下列預期和非預期停機期間保護您的資料：
導致短暫停機時間的客戶起始管理作業
服務維護作業
小規模網路或電源故障
涉及下列元件的問題和資料中心中斷：
支援服務的機器執行所在的機架
物理機器 ，負責承載執行 SQL 資料庫引擎 的虛擬機（VM）。 執行 SQL 資料庫引擎 的 VM
SQL 資料庫引擎 的問題
潛在的非計劃性局部中斷
欲了解更多關於 SQL 受管理執行個體 如何提供冗餘的資訊，請參見 Availability through local and zone redundancy。
對瞬態故障的彈性
暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中，而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤，通常透過重試受影響的請求來進行。
所有雲端託管應用程式在與任何雲端託管的 API、資料庫及其他元件通訊時，都應遵循 Azure 暫態故障處理指引。 如需詳細資訊，請參閱 處理暫時性錯誤的建議。
SQL 受管理執行個體 自動處理關鍵的服務任務，例如修補、備份，以及 Windows 和 SQL 資料庫引擎 升級。 它也會處理非計劃性事件，例如基礎硬體、軟體或網路故障。 SQL 受管理執行個體 即使在最關鍵的情況下也能快速復原，確保你的資料始終可用。 大多數的使用者不會注意到升級是持續進行的。
當您修補執行個體或容錯移轉時，如果您在應用程式中使用 重試邏輯，則對停機時間的影響很小。 您可以 測試應用程式對暫時性故障的復原能力。
對可用性區域故障的抵抗力
備註
區域備援目前不適用於下一代一般用途服務層級。
可用性區域是Azure區域內物理上獨立的資料中心群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。
啟用區域備援設定，可確保 SQL 受控執行個體在經歷大量失敗後仍有復原能力 (包括災難性資料中心中斷)，而無須變更應用程式邏輯。
SQL 受管理執行個體 透過將無狀態運算節點置於不同的可用區來實現區域冗餘。 它依賴於連接在目前包含活躍 SQL 資料庫引擎 程序的節點上的有狀態 ZRS。 若發生故障，SQL 資料庫引擎 程序會在其中一個無狀態運算節點啟動，接著存取有狀態儲存中的資料。
SQL 受管理執行個體 透過將 SQL managed instance 的副本置於多個可用區域，實現區域冗餘。 為了消除單一故障點，控制環路也會分布於多個區域進行複製。 控制平面流量會被路由至一個負載平衡器，而這個負載平衡器也會跨越可用區域部署。 Azure 流量管理員 控制從控制平面到負載平衡器的流量路由。
需求
Region 支援： SQL 托管實例的區域冗餘僅在特定區域獲得支援。 如需詳細資訊，請參閱支援的區域 (英文)。
備份儲存冗餘： 要啟用 SQL 管理實例的區域冗餘，請將備份儲存冗餘設為 ZRS 或 地理區域冗餘儲存 （GZRS）。
費用
當您啟用區域冗餘時，SQL 托管執行個體和區域冗餘備份會產生額外成本。 如需詳細資訊，請參閱定價。
您可以承諾在一段時間內以折扣費率使用計算資源 (包括業務關鍵服務層級中的區域備援執行個體)，以節省成本。 欲了解更多資訊，請參閱SQL 受管理執行個體 的保留方案。
設定可用性區域支援
本節說明如何設定 SQL 受控執行個體的可用性區域支援：
啟用區域備援： 若要瞭解如何在新的和現有執行個體上設定區域備援，請參閱 設定區域備援。
所有 SQL 受管理執行個體 的擴展操作，包括啟用區域冗餘，皆為線上操作，且幾乎不需要停機時間。 如需詳細資訊，請參閱 管理作業的持續時間。
停用區域備援：您可以按照啟用區域備援的相同步驟來停用區域備援。 此程序是類似於一般服務層級目標升級的線上作業。 在程序結束時，執行個體會從區域備援基礎結構移轉至單一區域基礎結構。
所有區域都狀況良好時的行為
本節說明當您的 SQL 受控執行個體設定為區域備援且所有可用性區域都可運作時，預期的情況：
區域間流量路由： 在正常操作中，請求會被路由到運行你SQL 受管理執行個體計算層的節點。
區域間的資料複製：資料庫檔案透過 ZRS 儲存在 Azure 儲存體，ZRS 會附加到目前包含活躍 SQL 資料庫引擎 程序的節點。
寫入作業是同步的，在資料成功複寫到所有可用性區域之前，不會被視為完成。 此同步復寫可確保區域失敗期間的強式一致性和零數據遺失。 不過，與本機備援儲存相比，它可能會導致寫入延遲稍高。
區域之間的流量路由：在正常作業期間，要求會路由傳送至 SQL 受控執行個體的主要複本。
區域之間的資料複寫：主要複本會持續且循序地將變更推送至不同可用性區域中的次要複本。 此程序可確保在提交每個交易之前，資料會保存在足夠數量的次要複本上。 這些複本位於不同的可用性區域。 此程序可確保在主要複本或可讀取的次要複本因故無法使用時，一律會有完全同步的複本可用於容錯移轉。
由於分區備援執行個體在不同的資料中心具有複本，且它們之間有一定的距離，因此增加的網路延遲可能會延長交易提交時間。 此增加可能會影響某些線上交易處理 （OLTP） 工作負載的效能。 多數應用程式對這種額外的延遲並不敏感。
區域失敗期間的行為
本節說明當您的 SQL 受控執行個體設定為區域備援，且一或多個可用性區域無法使用時，會發生什麼事：
- 偵測與回應： SQL 受管理執行個體負責偵測並回應可用性區域內的故障。 您不需要執行任何動作即可起始區域容錯移轉。
- 通知：Microsoft 不會在區域關閉時自動通知您。 不過，你可以使用 Azure 資源健康狀態 來監控單一資源的健康狀況，並且可以設定 資源健康狀態 警報來通知你問題。 你也可以使用 Azure 服務健康狀態 來了解整體服務的健康狀況，包括任何區域故障，並且可以設定 Service Health 警示來通知你問題。
- 作用中要求：當可用性區域無法使用時，在錯誤可用性區域中處理的任何要求都會終止，並且必須重試。 為了讓您的應用程式對這類問題具備韌性，請參閱「 對暫態故障的韌性 指引」。
Traffic rerouting： SQL 受管理執行個體 與 Service Fabric 合作，將資料庫引擎移至位於不同可用性區且有足夠空餘容量的合適無狀態運算節點。 容錯移轉完成後，新的連線會自動重新導向至新的主要計算節點。
繁重的工作負載在從一個計算節點轉換至另一個計算節點期間可能會遇到一些效能降低，因為新的資料庫引擎程序會從冷快取開始。
- Traffic recrouting： SQL 受管理執行個體 與 Service Fabric 合作，在另一個可用區域中選擇合適的副本作為主要副本。 當次要複本成為新的主要複本後，就會建立另一個次要複本，以確保叢集有足夠的複本數量來維持仲裁。 故障轉移完成後，新的連線會根據 連接字串 自動重新導向到新的主副本或可讀的次要副本。
預期停機時間：在可用性區域容錯移轉期間，可能會有短暫的停機時間。 停機時間通常少於 30 秒，若您的應用程式遵循 Resilience to transient faults 指引，應該能容忍此時間。
預期資料遺失：在可用性區域容錯移轉期間，已認可的交易應該不會遺失資料。 進行中的交易需要重試。
區域復原
當可用性區域恢復時，SQL 受管理執行個體 會與 Service Fabric 合作，恢復恢復區域內的操作。 客戶無須介入。
測試區域失敗
SQL 受管理執行個體 平台負責區域冗餘實例的流量路由、故障轉移與備援。 由於此功能完全受控，因此您不需要起始或驗證可用性區域失敗程式。 不過，您可以驗證應用程式對失敗的處理。
對區域範圍故障的復原能力
單一區域內部署一個獨立的 SQL 受管理執行個體。 不過，你可以在另一個 Azure 區域部署一個由 SQL 管理的次要實例，並設定 故障轉移群組。
容錯移轉群組
容錯移轉群組會自動將您的資料進行異地複寫，並且可在區域性失敗發生時，根據容錯移轉原則自動或手動容錯移轉。
本節摘要說明故障轉移群組的關鍵性資訊，但請務必檢閱 故障轉移群組概觀和最佳實務，以深入瞭解其運作方式及如何進行配置。
容錯移轉原則
在建立容錯移轉群組時，您可以選取容錯移轉原則，以指定負責偵測中斷及執行容錯移轉的人員。 ** 您可以設定兩種類型的故障轉移策略：
客戶管理的容錯移轉 （建議）： 當您使用客戶管理的容錯移轉原則時，您可以決定是否要執行 容錯移轉 （不會導致資料遺失） 或 強制容錯移轉 （這可能會造成資料遺失）。 強制容錯移轉可在主要執行個體無法存取時，作為中斷期間的復原方法。
Microsoft 管理的容錯移轉： Microsoft 管理的容錯移轉只會在特殊情況下使用，以觸發強制容錯移轉。
這很重要
使用由客戶管理的故障移轉選項來開發、測試和實施您的災難復原計劃。 請勿依賴 Microsoft 管理的容錯移轉，這可能只會在極端情況下使用。 Microsoft 管理的容錯移轉很可能會針對整個區域起始。 無法針對個別的容錯移轉群組、SQL 受控執行個體、訂用帳戶或客戶加以起始。 不同的 Azure 服務可能會在不同時間發生故障轉移。 我們建議您使用客戶自控容錯移轉。
需求
- Region support： 你可以為故障轉移群組中的 SQL 管理實例選擇任何 Azure 區域。 由於廣域網路的高延遲，異地複寫會使用非同步複寫機制。 若要減少網路延遲，請選取具有低延遲連線的區域。 欲了解更多關於Azure區域間延遲的資訊，請參見 Azure 網路往返延遲統計。
費用
當您在不同區域建立多個 SQL 受控執行個體時，每個 SQL 受控執行個體都需付費。
不過，如果您的次要執行個體沒有任何讀取工作負載或連線的應用程式，您可以將複本指定為待命執行個體，以節省授權成本。 更多資訊請參閱 配置 SQL 受管理執行個體 的免授權待命副本。
欲了解更多SQL 受管理執行個體價格資訊，請參閱 Service 價格資訊。
設定多區域支援
欲了解如何設定故障轉移群組，請參閱
容量規劃和管理
在容錯移轉期間，流量會重新導向至次要 SQL 受控執行個體。 請務必為您的次要 SQL 受控執行個體做好接收流量的準備。 使用與主要執行個體相同的服務層級、硬體世代和計算大小建立次要 SQL 受控執行個體。
如需在高可用性群組中調整 SQL 受控執行個體的詳細資訊，請參閱 調整執行個體。
當所有區域都正常時的行為
本節說明當 SQL 受控執行個體設定為使用多區域容錯移轉群組，且所有區域都可運作時，預期會發生什麼：
區域之間的流量路由：在正常作業期間，讀寫要求會移至主要區域中的單一主要執行個體。
容錯移轉群組也提供個別的唯讀接聽程式端點。 在正常操作中，此端點會連接到次要實例，以根據連接字串中指定的設定來路由唯讀流量。
如需容錯移轉群組如何將流量傳送至每個執行個體，以及如何將流量導向唯讀接聽程式端點的詳細資訊，請參閱 容錯移轉群組概觀和最佳實務。
區域之間的資料複寫：根據預設，資料會以非同步方式從主要執行個體複寫至次要 SQL 受控執行個體。
由於異地複寫是非同步的，如果您執行強制容錯移轉，可能會發生資料遺失。 您可以監視複寫延遲，以了解強制容錯移轉期間的潛在資料遺失。 如需詳細資訊，請參閱 DR 檢查清單。
如果您需要在故障切換期間消除非同步複寫造成的資料遺失，請將應用程式設定為封鎖呼叫執行緒，直到它確認上次認可的交易已在次要資料庫的交易記錄中傳輸並記錄完成為止。 這種方法需要自訂開發，而且會降低應用程式的效能。 如需詳細資訊，請參閱 防止遺失重要資料。
區域失敗期間的行為
本節說明當 SQL 受控執行個體設定為使用多區域容錯移轉群組，且主要區域發生中斷時，預期的情況：
偵測及回應：偵測及回應的責任取決於您的容錯移轉群組所使用的容錯移轉原則。
客戶管理的容錯移轉原則：您負責偵測區域中的失敗，並觸發相關作業，容錯移轉或強制容錯移轉至容錯移轉群組中的次要執行個體。
如果你執行故障轉移，SQL 受管理執行個體 會等待資料同步到次要實例後才執行故障轉移程序。
如果執行強制故障轉移，SQL 托管實例會立即將次要實例切換為主實例，而無需等待主實例的最新變更傳播。 此類型的容錯移轉可能會導致資料遺失。
Microsoft 管理的容錯移轉原則：Microsoft 管理的容錯移轉會在特殊情況下執行。 當 Microsoft 觸發容錯移轉時，容錯移轉群組會自動執行相關作業，強制容錯移轉至容錯移轉群組中的次要執行個體。 不過，我們建議對生產工作負載使用客戶管理的容錯移轉政策，以便控制容錯移轉發生的時間。
- 通知：Microsoft 不會在區域關閉時自動通知您。 不過，你可以使用 Azure 資源健康狀態 來監控單一資源的健康狀況，並且可以設定 資源健康狀態 警報來通知你問題。 你也可以使用 Azure 服務健康狀態 來了解整體服務的健康狀況，包括任何區域故障，並且可以設定 Service Health 警示來通知你問題。
目前作用中請求： 當發生故障轉移時，任何正在處理的請求都會被終止，並且必須重新嘗試。 為了讓您的應用程式對這類問題具備韌性，請參見 「對暫態故障的韌性」。
預期資料遺失： 資料遺失量取決於您設定應用程式的方式。 如需詳細資訊，請參閱 故障轉移群組概觀和最佳實務。
預期停機時間： 在容錯移轉群組容錯移轉期間，可能會有少量停機時間。 停機時間通常不到 60 秒。
流量重新路由： 容錯移轉群組完成容錯移轉後，讀寫流量會自動路由至新的主要執行個體。 如果您的應用程式在其連接字串中使用容錯移轉群組的端點，則無須在容錯移轉之後修改其連接字串。
區域復原
容錯移轉群組在還原時不會自動容錯回復至主要區域，您須責任起始容錯回復。
對於客戶管理的故障轉移群組，當主要區域已恢復時，即可啟動恢復。 對於 Microsoft 管理的故障轉移群組，故障回撥流程是自動進行的。 欲了解更多資訊，請參閱 回切至主要區域。
區域故障測試
您可以 測試容錯移轉群組。
測試容錯移轉群組只是執行 DR 演練的一部分。 如需詳細資訊，請參閱 執行 DR 演練。
備份與還原
備份資料庫以防範各種風險，包括資料遺失。 可以恢復備份以從意外數據丟失、損壞或其他問題中恢復。 備份與異地複寫不同，它們有不同的用途，並降低不同的風險。
SQL 受管理執行個體 會自動備份資料庫的完整、差異及交易日誌。 欲了解更多關於備份類型、頻率、還原能力、儲存成本及備份加密的資訊，請參閱SQL 受管理執行個體<>中的
SQL 受管理執行個體 提供內建的自動備份，並支援針對使用者資料庫發起的僅限複製備份。 如需詳細資訊，請參閱僅複製備份。
備份複寫
設定 SQL 受控執行個體的自動備份時，您可以指定備份的複寫方式。 設定為儲存在 ZRS 上的備份具有較高層級的復原能力。 建議您將備份設定為使用下列其中一種儲存類型：
ZRS 用於區域內的復原能力 (如果區域有可用性區域)
GZRS 可改善備份系統的跨區域復原能力，前提是該區域具有可用性區域，且配對至另一個區域。
如果您的區域不支援可用性區域，但有配對的區域，則使用 GRS
如需不同儲存體類型及其功能的詳細資訊，請參閱 備份儲存體備援。
異地復原
地理還原功能是一種基本的災難復原解決方案，允許你將備份副本還原到不同的 Azure 區域。 異地備份通常需要大量的停機時間和資料遺失。 若要在發生區域中斷時達到更高層級的可復原性，您應該 設定容錯移轉群組。
如果您使用異地還原，則必須考慮如何在次要區域中提供備份：
如果您的主要區域已配對，請使用 GZRS 或 GRS 備份儲存體來支援異地還原至配對區域的作業。
如果主要區域未配對，您可以建置自訂解決方案，將備份複寫到另一個區域。 請考慮使用使用者起始的僅複製備份，並將其儲存在儲存體帳戶中，以使用 Blob 物件複寫複寫至另一個區域中的儲存體帳戶。
服務維護的韌性
當 SQL 受管理執行個體 對你的實例進行維護時，SQL 管理實例仍保持完整可用，但可能會進行短暫的重新配置。 維護事件發生時，用戶端應用程式可能會觀察到短暫的連線中斷。 您的客戶應用程式應遵循「 韌性至暫態故障 」指引，以將影響降到最低。
SQL 受管理執行個體 讓你能指定一個通常用於服務升級及其他維護操作的維護時段。 設定維護時段可協助您將任何副作用降到最低，例如在工作時間內自動容錯移轉。 您也可以接收計劃性維護的預先通知。
更多資訊請參閱SQL 受管理執行個體中的
服務等級協定
Azure 服務的服務層級協議（SLA）描述了每項服務的預期可用性，以及您的解決方案必須符合的條件，以達成該可用性預期。 欲了解更多資訊，請參閱線上服務的服務等級協議。
對於 SQL 受管理執行個體，可用性 SLA 只有在你的 Azure 虛擬網路設定正確時才適用，避免阻礙管理流量。 此設定包括子網路大小、網路安全性群組 （NSG）、使用者定義路由 （UDR）、DNS 設定，以及影響網路資源管理和使用的其他資源。 欲了解更多關於SQL 受管理執行個體所需網路配置的資訊，請參閱 Network requirements。
相關內容
- 使用 SQL 受管理執行個體 的業務持續性概述
- 高可用性和災害復原檢查清單
- Azure 中的可靠性