使用 Azure SQL Database 彈性集區的應用程式災害復原策略

適用於：Azure SQL 資料庫

Azure SQL Database 提供許多功能，以在災難事件發生時確保應用程式的商務持續性。 彈性集區和單一資料庫支援相同類型的災害復原 (DR) 功能。 本文描述了幾種針對使用這些 Azure SQL Database 業務持續性功能的彈性池的災難復原策略。

本文使用下列標準 SaaS 獨立軟體廠商 （ISV） 應用程式模式：

現代化雲端型 Web 應用程式會為每位終端使用者佈建一個資料庫。 ISV 有許多客戶，因此會使用多個資料庫 (稱為租用戶資料庫)。 因為租戶資料庫通常具有難以預測的使用模式，所以 ISV 會使用彈性集區，使資料庫成本在較長一段時間內更可預測。 彈性集區也可在使用者活動尖峰時簡化效能管理。 除了租戶資料庫外，應用程式還使用多個資料庫來管理使用者設定檔、安全性、收集使用模式等。個別租戶的可用性不會影響整個應用程式的可用性。 不過，管理資料庫的可用性和效能對應用程式的功能而言十分重要，且如果管理資料庫離線，整個應用程式也會離線。

本文會討論涵蓋各種案例 (從成本導向創業應用程式以至具有嚴格可用性需求的應用程式) 的 DR 策略。

注意

如果您目前使用進階或業務關鍵資料庫和彈性集區，您可以將它們轉換成區域備援部署組態，使它們具備區域中斷復原能力。 請參閱區域備援資料庫。

案例 1. 成本導向創業

我是新創公司，對成本非常敏感。 我想要簡化應用程式的部署和管理，而且我可以為個別客戶提供受限的 SLA。 但是我想要確保整個應用程式絕不會離線。

若要滿足簡單性需求，請將所有租用戶資料庫部署到您所選擇 Azure 區域中的單一彈性集區，並將管理資料庫部署為異地複寫的單一資料庫。 針對租戶的災害復原，請使用 地理還原，而不需要額外費用。 若要確保管理資料庫的可用性，請使用容錯移轉群組將它們異地複寫到另一個區域 (步驟 1)。 此案例中災害復原組態的持續成本等於次要資料庫的總成本。 下圖說明此組態。

如果主要區域中斷，下圖說明讓您的應用程式上線的復原步驟。

• 容錯移轉群組會啟動管理資料庫自動容錯移轉至 DR 區域。 應用程式會自動重新連線到新的主要區域，並且會在 DR 區域中建立所有新的帳戶和租用戶資料庫。 現有的客戶會看到其資料暫時無法使用。
• 使用與原始集區 (2) 相同的組態來建立彈性集區。
• 使用異地還原建立租用戶資料庫 (3) 的複本。 您可以考慮透過使用者連接來觸發個別還原，或使用某個其他應用程式特有的優先順序配置。

您的應用程式目前在 DR 區域中已重新上線，但有些客戶在存取其資料時會經歷到延遲。

如果服務是暫時中斷，則在 DR 區域完成所有資料庫還原之前，Azure 可能已復原主要區域。 在此情況下，請安排將應用程式移回主要區域。 此程序會採取下圖上所說明的步驟。

• 取消所有未處理的異地還原要求。
• 將管理資料庫容錯移轉至主要區域 (5)。 在該區域復原後，原先的主要節點已自動成為次要節點。 現在，它們會再次切換角色。
• 變更應用程式的連接字串，使其重新指向主要區域。 現在，系統會在主要區域中建立所有新的帳戶和租用戶資料庫。 部分現有客戶會發現其資料暫時無法使用。
• 請將 DR 集區中的所有資料庫都設定為唯讀，確保在 DR 區域 (6) 中無法修改它們。
• 對於已在復原後變更之 DR 集區中的每個資料庫，重新命名或刪除主要集區 (7) 中的對應資料庫。
• 將更新的資料庫從 DR 集區複製到主要集區 (8)。
• 刪除 DR 集區 (9)

此時，您的應用程式已在主要區域上線，且所有租用戶資料庫皆可在主要集區中使用。

優點

這項策略的重要 優點 是資料層備援的持續成本很低。 Azure SQL Database 會自動備份資料庫，不會重寫應用程式，也不需額外費用。 只有在還原彈性資料庫時，才會產生成本。

取捨

取捨在於所有租用戶資料庫的完整復原需要很長的時間。 時間長短取決於您在 DR 區域中起始的總還原次數，和租用戶資料庫的整體大小。 即使您優先處理某些租用戶的還原作業，而非其他租用戶的還原作業，您仍會與在相同區域中啟動的所有其他還原作業競爭，因為服務會進行協調並節流，以將對現有客戶資料庫造成的整體影響降到最低。 此外，除非在 DR 區域中建立新的彈性集區，否則無法啟動租用戶資料庫的復原。

案例 2. 具有分層服務的成熟應用程式

我是一個成熟的 SaaS 應用程式，其中包含分層式服務供應專案，以及適用於試用客戶和付費客戶的不同 SLA。 對於試用版客戶，我必須盡可能降低成本。 試用客戶可以接受停機，但我想降低其發生的可能性。 對於付費客戶，任何停機時間都是風險。 因此，我想要確定付費客戶一律可以存取其資料。

若要支援此情境，請將試用租用戶與付費租用戶分別放入不同的彈性集區，以將兩者區隔開來。 試用客戶每個租用戶可用的 eDTU 或 vCore 較少，SLA 較低，且復原時間較長。 付費客戶所在集區中每個租用戶的 eDTU 或虛擬核心和 SLA 都較高。 為了保證最低的復原時間，我們會對付費客戶的租用戶資料庫進行異地複寫。 下圖說明此組態。

與第一個案例相同，管理資料庫會相當活躍，因此針對它使用單一異地複寫的資料庫 (1)。 這可確保新客戶訂用帳戶、設定檔更新和其他管理作業的可預測效能。 主要管理資料庫複本所在區域是主要區域，而次要管理資料庫複本所在區域是 DR 區域。

付費客戶的租用戶資料庫在主要區域中佈建的 paid 集區內具有作用中的資料庫。 在 DR 區域佈建名稱相同的次要集區。 每個租戶都會異地複寫至次要集區 (2)。 這可透過容錯移轉快速復原所有租用戶的資料庫。

如果主要區域中斷，下圖說明讓您的應用程式上線的復原步驟：

• 將管理資料庫立即容錯移轉到 DR 區域 (3)。
• 變更應用程式的連接字串，使其指向災害復原區域。 現在，系統會在 DR 區域中建立所有新的帳戶和租用戶資料庫。 現有試用版客戶會發現其資料暫時無法使用。
• 將付費租用戶的資料庫容錯移轉至 DR 區域中的集區，以立即恢復其可用性 (4)。 由於容錯移轉只是中繼資料層級的快速變更，因此請考慮採用一種最佳化做法，讓個別容錯移轉由終端使用者連線視需要觸發。
• 如果次要集區的 eDTU 大小或 vCore 值低於主要集區，是因為次要資料庫在作為次要資料庫時只需要有能力處理變更記錄，請立即提高集區容量，以支援所有租用戶 (5) 的完整工作負載。
• 為試用客戶的資料庫 (6) 在 DR 區域中建立名稱和組態都相同的新彈性集區。
• 建立試用客戶集區之後，請使用異地還原，將個別試用租用戶資料庫還原至新的集區 (7)。 請考慮透過使用者連接來觸發個別還原，或使用某個其他應用程式特有的優先順序配置。

此時，您的應用程式會在DR區域中重新上線。 所有付費客戶都可以存取其資料，而試用版客戶在存取其資料時會經歷到延遲。

當 Azure 在您於 DR 區域還原應用程式 之後 復原主要區域時，您可以繼續讓應用程式在該區域執行，也可以決定容錯移轉回主要區域。 如果主要區域在完成容錯移轉程序之前已復原，請考慮立即容錯回切。 故障回復會依照下圖所示步驟進行：

• 取消所有未處理的異地還原要求。
• 將管理資料庫容錯移轉 (8)。 在該區域復原後，舊的主要節點會自動成為次要節點。 現在它又成為主要的了。
• 將付費租用戶資料庫容錯移轉 (9)。 同樣地，在該區域復原後，原先的主要節點會自動成為次要節點。 現在它們又成為主要項目。
• 將 DR 區域中變更的已還原試用版資料庫設定為唯讀 (10)。
• 對於已在復原後變更之試用版客戶 DR 集區中的每個資料庫，重新命名或刪除試用版客戶主要集區 (11) 中的對應資料庫。
• 將更新的資料庫從 DR 集區複製到主要集區 (12)。
• 刪除 DR 集區 (13)。

注意

容錯移轉作業為非同步。 若要將復原時間降到最低，請務必分批執行租戶資料庫的容錯移轉命令，且每批至少包含 20 個資料庫。

優點

這項策略的重要 優點 在於它可為付費客戶提供最高的 SLA。 它也可確保在建立試用 DR 集區後，新的試用會立即解除封鎖。

取捨

權衡點在於，這項設定會使租用戶資料庫的總成本增加，而增加的部分相當於付費客戶次要 DR 集區的成本。 此外，如果次要集區的大小不同，付費客戶在容錯移轉後的效能會較低，直到 DR 區域中的集區升級完成為止。

案例 3. 具有分層服務的分散式應用程式

我已有完善且提供分層服務的 SaaS 應用程式。 我想要將非常積極的 SLA 提供給付費客戶，並在中斷時將影響風險降到最低，因為即使是短暫中斷也可能造成客戶不滿。 付費客戶務必一律可以存取其資料。 試用版是免費的，而且在試用期間未提供 SLA。

若要支援此案例，請使用三個獨立的彈性集區。 將大小相同且每個資料庫都具有高 eDTU 或虛擬核心的兩個集區佈建到兩個不同的區域，以包含付費客戶的租用戶資料庫。 包含試用版租用戶的第三個集區可在每個資料庫具有較低 eDTU 或虛擬核心，並佈建到兩個區域中的其中一個。

為了保證中斷期間的最低復原時間，我們會在這兩個區域使用 50% 的主要資料庫來異地複寫付費客戶的租用戶資料庫。 同樣地，每個區域都有 50% 的次要資料庫。 這樣一來，如果某個區域離線，則只有 50% 的付費客戶資料庫會受到影響，並且必須進行容錯移轉。 其他資料庫會保持不變。 下圖說明此組態：

與先前的案例相同，管理資料庫會相當活躍，因此請將它們設定為單一異地複寫的資料庫 (1)。 這可確保新客戶訂用帳戶、配置檔更新和其他管理作業的可預測效能。 區域 A 是管理資料庫的主要區域，而區域 B 會用於復原管理資料庫。

付費客戶的租用戶資料庫也會進行異地複寫，但其主要複本與次要複本會分設於區域 A 和區域 B 之間 (2)。 如此一來，受停電影響的租戶主要資料庫就能切換到另一個區域並開放使用。 另一半的租戶資料庫完全沒有受到影響。

下圖說明在區域 A 中斷時要採取的復原步驟。

• 將管理資料庫立即容錯移轉到區域 B (3)。
• 變更應用程式的連接字串以指向區域 B 中的管理資料庫。修改管理資料庫，確定系統是在區域 B 中建立新的帳戶和租用戶資料庫，而且那裡也有現有的租用戶資料庫。 現有試用版客戶會發現其資料暫時無法使用。
• 將付費租用戶的資料庫容錯移轉到區域 B 中的集區 2，以立即還原其可用性 (4)。 因為故障轉移是快速的元數據層級變更，您可以考慮優化方案，即根據最終用戶連線的需求觸發個別故障轉移。
• 現在，因為集區 2 只包含主要資料庫，所以集區中的總工作負載會增加，而且可以立即增加其 eDTU 大小 (5) 或虛擬核心數量。
• 在區域 B 中，為試用客戶的資料庫 (6) 建立一個名稱和組態都相同的新彈性集區。
• 建立集區後，請使用異地還原功能，將個別試用租用戶資料庫還原到集區 (7)。 您可以考慮透過使用者連接來觸發個別還原，或使用某個其他應用程式特有的優先順序配置。

注意

容錯移轉作業為非同步。 若要將復原時間降至最低，請務必分批執行租戶資料庫的容錯移轉命令，每批至少 20 個資料庫。

您的應用程式目前在區域 B 中已重新上線。所有付費客戶都可以存取其資料，而試用版客戶在存取其資料時會經歷到延遲。

在區域 A 復原時，您需要決定是否要使用區域 B 作為試用客戶的所在地，或者恢復使用區域 A 中的試用客戶集區。判斷的其中一個標準可能是自復原後試用租用戶資料庫有多少次變更（%）的次數。 無論做出何種決定，您都需要在兩個集區之間重新平衡付費租戶的分配。 下圖說明當試用版租用戶資料庫容錯回復至區域 A 時的程序。

• 取消試用版 DR 集區所有尚未完成的異地還原請求。
• 將管理資料庫容錯移轉 (8)。 在該區域恢復後，原先的主要節點會自動成為次要節點。 現在它又成為主要的了。
• 選取哪些付費租戶資料庫要容錯回復至集區 1，並啟動對其次要複本的容錯移轉 (9)。 復原區域之後，集區 1 中的所有資料庫都已自動成為次要資料庫。 現在，其中的 50% 會再次變成主要。
• 將集區 2 的大小減少為原始 eDTU (10) 或虛擬核心數量。
• 將區域 B 中的所有已還原試用版資料庫設定為唯讀 (11)。
• 對於已在復原後變更之試用版 DR 集區中的每個資料庫，重新命名或刪除試用版主要集區 (12) 中的對應資料庫。
• 將更新的資料庫從 DR 集區複製到主要集區 (13)。
• 刪除 DR 集區（14）。

優點

這項策略的重要 優點 如下：

• 它支援付費客戶最嚴格的服務等級協議（SLA），確保停電不會影響超過50% 的租戶資料庫。
• 它可確保在復原期間一建立 trail DR 集區，新的試用就會立即解除封鎖。
• 它允許更有效率地使用集區容量，因為集區 1 和集區 2 中 50% 的次要資料庫比主要資料庫還不活躍。

取捨

主要 取捨 如下：

• 對於連線到區域 A 的終端使用者，相較於連線到區域 B 的終端使用者，對管理資料庫執行 CRUD 作業時的延遲較低，因為這些作業是在管理資料庫的主要複本上執行。
• 需要更複雜的管理資料庫設計。 例如，每個租戶記錄都有一個需要在容錯移轉和容錯回復期間變更的位置標籤。
• 在區域 B 中的集區升級完成之前，付費客戶可能會遇到比平常低的效能。

摘要

本文著重於SaaS ISV 多租用戶應用程式所使用之資料庫層的災害復原策略。 您選擇的策略是以應用程式的需求為基礎，例如商務模型、您想要提供給客戶的 SLA、預算限制等。每個描述的策略都會概述優點和取捨，以便做出明智的決策。 此外，特定應用程式可能包含其他 Azure 元件。 因此，您需要檢閱他們的業務持續營運指引，並與他們共同協調資料庫層的復原作業。 若要深入了解如何管理 Azure 中資料庫應用程式的復原，請參閱設計災害復原的雲端解決方案。

後續步驟

• 若要了解 Azure SQL Database 自動備份，請參閱 Azure SQL Database 自動備份。
• 如需商務持續性概觀和案例，請參閱 商務持續性概觀。
• 若要了解如何使用自動備份進行復原，請參閱 從服務起始的備份還原資料庫。
• 若要了解更快速的復原選項，請參閱主動式異地複寫和容錯移轉群組。
• 若要了解如何使用自動備份進行封存，請參閱 資料庫複製。