使用 Azure SQL 受控執行個體的商務持續性概觀 \(部分機器翻譯\)
適用於：
Azure SQL 受控執行個體
本文概述 Azure SQL 受控執行個體的商務持續性和災害復原功能，說明從可能造成資料遺失或導致執行個體和應用程式無法使用的中斷事件中復原的選項和建議。 了解當使用者或應用程式錯誤影響資料完整性、Azure 可用性區域或區域中斷，或您的應用程式需要維護時該如何處理。
概觀
Azure SQL 受控執行個體中的商務持續性指透過提供可用性、高可用性和災害復原，讓您的企業在中斷時繼續運作的機制、原則和程序。
在大部分情況下，SQL 受控執行個體會處理雲端環境中可能發生的干擾性事件，並讓您的應用程式和商務程序能夠持續執行。 不過，有些中斷事件可能需要一些時間才能緩解，例如：
- 使用者不小心刪除或更新了資料表中的資料列。
- 惡意攻擊者成功刪除資料或刪除資料庫。
- 重大自然災害事件會撤下資料中心或者可用性區域或區域。
- 罕見的資料中心、可用性區域或全區域中斷，原因是設定變更、軟體錯誤或硬體元件故障。
可用性
Azure SQL 受控執行個體隨附核心復原和可靠性承諾，可防止軟體或硬體失敗。 資料庫備份是自動執行的，可保護您的資料免於損毀或意外刪除。 作為平台即服務 (PaaS)，Azure SQL 受控執行個體服務以現成功能的形式提供可用性，其可用性 SLA 高達 99.99%，為行業領先水平。
高可用性
若要在 Azure 雲端環境中實現高可用性，請啟用區域備援，以便執行個體使用可用性區域，並確保能夠從區域性失敗中復原。 許多 Azure 區域提供可用性區域，這些區域是區域內獨立的資料中心群組，具有獨立的電源、冷卻和網路基礎結構。 如果一個區域發生中斷，可用性區域的作用是在其餘區域中提供區域服務、容量和高可用性。 透過啟用區域備援，執行個體能夠從區域性硬體和軟體失敗中復原，且復原對應用程式而言是透明的。 啟用高可用性時，Azure SQL 受控執行個體服務可以提供 99.99% 的更高可用性 SLA。
災害復原
若要跨區域達到更高的可用性和備援，您可以啟用災害復原功能，以從災難性的區域故障中快速復原執行個體。 Azure SQL 受控執行個體的災害復原選項包括：
- 容錯移轉群組可啟用主要和次要執行個體之間的連續同步處理。 容錯移轉群組提供保持不變的讀寫和唯讀接聽程式端點，因此無需在容錯移轉後更新應用程式連接字串。
- 當您無法透過在任何 Azure 區域中的任何現有執行個體上建立新資料庫來存取主要區域中的資料庫時，異地還原可讓您從異地複寫備份進行還原，以從區域中斷中復原。
提供商務持續性的功能
例如，有四個主要的可能中斷案例。 下表列出 SQL 受控執行個體商務持續性功能，可用來緩解潛在的商務中斷案例：
| 商務中斷案例 | 商務持續性功能 |
|---|---|
| 影響資料庫節點的本機硬體或軟體失敗。 | 為了減緩本機硬體和軟體失敗，SQL 受控執行個體包括可用性架構，確保可會從這些失敗中自動復原、最高可達 99.99% 的可用性 SLA。 |
| 通常由應用程式 Bug 或人為錯誤所造成的資料損毀或刪除。 這類失敗是應用程式特有的，且服務通常偵測不到。 | 為了保護您的企業免於遺失資料，SQL 受控執行個體每週均會自動建立完整資料庫備份、通常每 12 或 24 小時就會進行差異資料庫備份，而且每 5 - 10 分鐘就會進行交易記錄備份。 根據預設，備份會儲存在異地備援儲存體七天，並支援可設定備份保留期間，以實現長達 35 天的時間點還原。 如果執行個體尚未刪除，或者您已設定長期保留，則您可以將已刪除的資料庫還原到被刪除的時間點。 |
| 罕見的資料中心或可用性區域中斷，可能是由自然災害事件、設定變更、軟體錯誤或硬體元件故障所致。 | 若要減輕資料中心或可用性區域層級中斷，請為 SQL 受控執行個體啟用區域備援，以使用 Azure 可用性區域，並在 Azure 區域內的多個實體區域提供備援。 啟用區域備援可確保受控執行個體能夠抵禦區域性失敗，提供高達 99.99% 的高可用性 SLA。 |
| 影響所有可用性區域及其內的資料中心的罕見區域性中斷，可能是由災難性的自然災害事件所致。 | 若要緩解整個區域的中斷，請使用下列選項之一啟用災害復原： - 與容錯移轉群組連續資料同步，在次要區域中建立複本以進行容錯移轉。 - 將 [備份儲存體備援] 設定為 [異地備援備份儲存體]，以使用 [異地還原]。 |
RTO 和 RPO
當您開發商務持續性計畫時，請了解應用程式在干擾性事件之後完全復原所需的最大可接受時間。 應用程式完全復原所需的時間稱為復原時間目標 (RTO)。 另請了解在從非計劃性干擾性事件中復原時，應用程式可以容許遺失的最近資料更新 (時間間隔) 最大期間。 潛在的資料遺失稱為復原點目標 (RPO)。
下表比較每個商務持續性選項的 RPO 和 RTO：
| 商務持續性選項 | RTO (停機時間) | RPO (資料遺失) |
|---|---|---|
| 高可用性 (使用區域備援) |
通常短於 30 秒 | 0 |
| 災害復原 (搭配使用容錯移轉群組與客戶管理的容錯移轉原則) |
通常短於 60 秒 | 等於或大於 0 (取決於尚未復現的中斷事件發生之前的資料更改) |
| 災害復原 (使用異地還原) |
12 小時 | 1 小時 |
商務持續性檢查清單
如需將可用性最大化並最大程度提高商務持續性的規範性建議，請參閱：
復原相同 Azure 區域內的資料庫
您可以使用自動資料庫備份，將資料庫還原至過去的時間點。 如此一來，您就能從人為錯誤所造成的資料損毀中復原。 時間點還原 (PITR) 可讓您在相同執行個體或不同執行個體中建立新的資料庫，以代表發生損毀事件之前的資料狀態。 還原作業是資料作業的大小，也取決於目標執行個體的目前工作負載。 復原非常大型或非常活躍的資料庫，可能需要比較長的時間。 如需復原時間的詳細資訊，請參閱資料庫復原時間。
如果支援用來進行時間點還原 (PITR) 的最大備份保留期間不足以滿足應用程式，則您可透過為資料庫設定長期保留 (LTR) 原則來延長該期間。 如需詳細資訊，請參閱長期備份保留。
將資料庫復原到現有的執行個體
雖然很罕見，但 Azure 資料中心也可能會中斷。 發生中斷時，可能只會讓業務中斷幾分鐘，也可能會持續幾小時。
- 其中一個選項是等待您的執行個體在資料中心中斷結束之後重新上線。 這適用於可以容忍資料庫離線的應用程式。 例如，您不需要不斷處理的開發專案或免費試用版。 當資料中心中斷時，您不會知道中斷可能持續多久，因此，這個選項只有在您不需要資料庫時才可行。
- 如果您正在使用異地備援 (GRS) 或異地區域備援 (GZRS) 儲存體，另一個選項是使用異地備援資料庫備份 (異地還原) 將資料庫還原至任何 Azure 區域中的任何 SQL 受控執行個體。 異地還原使用異地備援備份做為其來源，即使因為中斷而無法存取資料庫或資料中心，也能用來將資料庫復原至最後一個可用的時間點。 您可以在配對區域中找到可用的備份。
- 最後，如果您已使用執行個體的容錯移轉群組來設定異地次要資料庫，請使用客戶 (建議) 或 Microsoft 受管的容錯移轉，即可快速從中斷中復原。 雖然容錯移轉本身只需要幾秒鐘的時間，但如果已設定，服務至少需要 1 小時，才能啟用 Microsoft 受管的異地容錯移轉。 這是依據中斷的規模來確保容錯移轉之正當性的必要作法。 此外，由於配對區域之間的非同步複寫本質，故容錯移轉可能會導致最近的變更資料遺失。
當您開發商務持續性計劃時，您必須了解應用程式在干擾性事件之後完全復原所需的最大可接受時間。 完全復原應用程式所需的時間稱為復原時間目標 (RTO)。 您也必須了解在從非計劃性干擾性事件中復原時，應用程式可以容許遺失的最近資料更新 (時間間隔) 最大期間。 潛在的資料遺失稱為復原點目標 (RPO)。
不同的復原方法會提供不同層級的 RPO 和 RTO。 您可以選擇特定的復原方法，或使用方法組合來實現完整的應用程式復原。
如果您的應用程式符合下列任何準則，請使用容錯移轉群組：
- 是關鍵性應用程式。
- 具有不允許 12 小時或以上之停機時間的服務等級協定 (SLA)。
- 停機可能會衍生財務責任。
- 具有很高的資料變更率，且無法接受為時 1 小時的資料遺失。
- 與潛在的財務責任和相關企業損失相較下，使用主動式異地複寫的額外成本較低。
您可根據應用程式需求，選擇使用資料庫備份和容錯移轉群組的組合。
下列各節概述使用資料庫備份或容錯移轉群組來進行復原的步驟。
準備中斷
無論您要使用何種商務持續性功能，您都必須︰
- 識別並準備目標執行個體，包括網路 IP 防火牆規則、登入和
master資料庫層級權限。 - 決定如何將用戶端和用戶端應用程式重新導向到新的執行個體
- 記錄其他相依性，例如稽核設定和警示
如果您沒有適當地準備，在容錯移轉或資料庫復原後讓應用程式上線將會多花費時間，而且也可能需要在有壓力的情況下進行疑難排解，這是不良的情況組合。
容錯移轉至異地複寫的次要執行個體
若您使用容錯移轉群組作為復原機制，則可設定自動容錯移轉原則。 啟動容錯移轉後，次要執行個體就會成為新的主要執行個體，並準備好記錄新的交易以及回應查詢，只會遺失尚未複寫的資料。
注意
當資料中心重新上線時，舊的主要執行個體就會自動重新連線至新的主要執行個體，並成為次要執行個體。 若您需要將主要複本重新定位至原始區域，可手動啟動規劃的容錯移轉 (容錯回復)。
執行異地還原
如果您正在使用自動備份搭配異地備援儲存體 (當您建立執行個體時的預設儲存體選項)，您可以使用異地還原來復原資料庫。 復原通常會在 12 小時內進行，且可能遺失最多 1 小時的資料 (視最後一次記錄備份的建立並複寫時間而定)。 在復原完成之前，資料庫無法記錄任何交易或回應任何查詢。 請注意，異地還原只會將資料庫還原至最後一個可用的時間點。
注意
如果資料中心在您的應用程式切換到復原的資料庫之前就重新上線，則您可以取消復原。
執行容錯移轉後/復原後工作
從其中任何一種復原機制復原之後，您都必須執行下列額外的工作，您的使用者和應用程式才能回復正常執行狀態︰
- 將用戶端與用戶端應用程式重新導向至新的執行個體和還原的資料庫。
- 確定有適當的網路 IP 防火牆規則供使用者連線。
- 確定有適當的登入和
master資料庫層級權限 (或使用自主使用者)。 - 視情況設定稽核。
- 視情況設定警示。
注意
如果您使用容錯移轉群組，並使用讀寫接聽程式來連線至執行個體，即會針對應用程式以自動且明確的方式進行容錯移轉後的重新導向。
免授權 DR 複本
您可以將次要 Azure SQL 受控執行個體設定為僅用於災害復原 (DR)，以節省授權成本。 如果您在兩個 SQL 受控執行個體之間使用容錯移轉群組，或您已設定 SQL Server 與 Azure SQL 受控執行個體之間的混合式連結，則可取得這項權益。 只要次要執行個體上沒有任何讀取或寫入工作負載，而且只是被動 DR 待命，您就不需支付次要執行個體所使用的虛擬核心授權成本。
在您指定次要執行個體僅用於災害復原，且執行個體上沒有執行讀取或寫入工作負載時，Microsoft 會根據容錯移轉權限權益，向您免費提供主要執行個體已獲得授權的虛擬核心數目。 您仍會支付次要執行個體所使用的計算和儲存體費用。 如需混合式容錯移轉權限權益的確切條款及條件，請參閱 SQL Server – 容錯移轉權限一節中的線上 SQL Server 授權條款規定。
權益的名稱取決於您的案例：
- 被動複本的混合式容錯移轉權限：當您設定 SQL Server 與 Azure SQL 受控執行個體之間的連結時，您可以使用混合式容錯移轉權限權益來節省被動次要複本的虛擬核心授權成本。
- 待命複本的容錯移轉權限：當您在兩個受控執行個體之間設定容錯移轉群組時，您可以使用容錯移轉權限權益來節省待命次要複本的虛擬核心授權成本。
下列圖表示範了每個案例的優點：
下一步
若要深入了解商務持續性功能，請參閱自動化備份和容錯移轉群組。 如需災害復原，請參閱復原資料庫並針對 Azure SQL 受控執行個體啟用 區域備援。