使用作用中異地複寫 SQL 資料庫管理雲端應用程式的輪流升級

適用於：Azure SQL 資料庫

瞭解如何使用 Azure SQL 資料庫異地複寫來啟用雲端應用程式的輪流升級。 因為升級屬干擾性操作，所以應該是商務持續性方案和設計的一部分。 本文中，我們會探討兩種不同的方法來協調升級程序，並討論每個選項的優點和取捨。 針對本文目的，我們會參考由連線至單一資料庫作為其資料層之網站所組成的應用程式。 我們的目標是將應用程式第 1 版 (V1) 升級至第 2 版 (V2)，且不造成任何使用者體驗的顯著影響。

評估升級選項時，請考慮下列因素：

• 升級期間對應用程式可用性的影響，例如應用程式功能可能會有所限制或降級的時間長短。
• 升級失敗時復原的能力。
• 如果升級期間發生不相關災難性失敗，表示應用程式存在弱點。
• 總成本。 此因素包括升級程序使用之暫存元件的額外資料庫備援和累加成本。

升級依賴資料庫備份進行災害復原的應用程式

如果您的應用程式依賴自動資料庫備份，並使用異地還原進行災害復原，則會部署到單一 Azure 區域。 欲將使用者中斷可能性降到最低，請在該區域中建立預備環境，其中包含升級所涉及的所有應用程式元件。 第一張圖表說明了升級程序前的作業環境。 端點 contoso.azurewebsites.net 代表了 Web 應用程式的實際執行環境。 欲能夠復原升級，您必須建立具有資料庫完整同步複本的預備環境。 請遵循下列步驟來為升級建立預備環境：

1. 在相同的 Azure 區域中建立次要資料庫。 監視次要資料庫，查看植入程序是否已完成 (1)。
2. 為您的 Web 應用程式建立新的環境，並將其稱之「預備」。 這將會在 Azure DNS 中註冊 URL contoso-staging.azurewebsites.net (2)。

請注意

這些準備步驟不會影響可在完整存取模式中運作的生實際執行環境。

當準備步驟完成，應用程式即準備好進行真正的升級。 下圖說明了升級程序所涉及的步驟：

1. 將主要資料庫設定為唯讀模式 (3)。 此模式可確保 Web 應用程式 (V1) 的實際執行環境在升級期間保持唯讀狀態，因而防止 V1 和 V2 資料庫執行個體之間的資料分歧。
2. 使用計畫終止模式來中斷次要資料庫連線 (4)。 此動作會建立與主要資料庫完全同步、獨立的複本。 此資料庫將會升級。
3. 將次要資料庫轉成讀寫模式，然後執行升級指令 (5)。

如果升級順利完成，您現已準備好切換使用者至升級的複本應用程式，這會成為實際執行環境。 切換涉及幾個步驟，如下圖所示：

1. 啟用 Web 應用程式的實際執行環境與預備環境之間的交換操作 (6)。 這項操作會切換兩個環境的 URL。 現在 contoso.azurewebsites.net 會指向網站的 V2 版本和資料庫（實際執行環境）。
2. 如果您不再需要 V1 版本，這會在交換後變成預備環境複本，您可以停止使用預備環境 (7)。

如果升級程序失敗（例如，升級指令發生錯誤），請確認是否預備環境受到損害。 欲將應用程式復原至升級前狀態，請將實際執行環境中的應用程式還原為完整存取權。 下圖顯示了反轉步驟：

1. 請設定資料庫複本為讀寫模式 (8)。 此動作會還原實際執行複本的完整 V1 功能。
2. 執行根本原因分析和停止使用預備環境 （9）。

此時，應用程式已完全正常運作，您可以重複升級步驟。

注意

回復不需要 DNS 變更，因為您尚未執行交換操作。

此選項的主要優點在於，可以遵循一組簡單的步驟，在單一區域中升級應用程式。 升級的成本相對較低。

主要取捨在於，如果在升級期間發生重大失敗，升級前狀態的恢復涉及不同的區域中重新部署的應用程式，並使用異地復原從備份來還原資料庫。 此程序會導致顯著的停機時間。

升級依賴資料庫異地複寫進行災害復原的應用程式

如果您的應用程式使用作用中異地複寫或失敗群組進行商務持續性，則會部署至至少兩個不同的區域。 主要區域中有作用中的主要資料庫，以及備份區域中唯讀的次要資料庫。 除了本文開頭所述的因素外，升級程序也必須保證：

• 升級程序期間，應用程式隨時都會受到保護，以免發生災難性失敗。
• 應用程式的異地備援元件會與作用中元件平行升級。

欲達成這些目標，除了使用 Web Apps 環境之外，您還會藉由容錯移轉設定檔搭配一個作用中端點和一個備份端點來趁機利用 Azure 流量管理員。 下一張圖表說明了升級程序前的作業環境。 網站 contoso-1.azurewebsites.net 和 contoso-dr.azurewebsites.net 代表了具完整異地備援的應用程式之實際執行環境。 實際執行環境包括下列元件：

• 主要區域中 Web 應用程式 contoso-1.azurewebsites.net 的實際執行環境 (1)
• 主要區域中的主要資料庫 (2)
• 備份區域中 Web 應用程式的待命執行個體 (3)
• 備份區域中異地複寫的次要資料庫 (4)
• 流量管理員效能設定檔包含名為 contoso-1.azurewebsites.net 的線上端點和名為 contoso-dr.azurewebsites.net 的離線端點

欲可復原升級，您必須建立具應用程式完整同步複本的預備環境。 因您必須確保應用程式可在升級程序間發生災難性失敗時快速復原，預備環境也必須是異地備援。 欲為生級建立預備環境，必須遵循下列步驟：

1. 在主要區域中部署 Web 應用程式的預備環境 (6)。
2. 在主要的 Azure 區域中建立次要資料庫 (7)。 設定 Web 應用程式的預備環境來連線。
3. 藉由複寫主要區域中的次要資料庫，在備份區域中建立另一個異地備援的次要資料庫。 （此方法稱之 鏈式異地複寫。）(8)。
4. 在備份區域 (9) 中部署 Web 應用程式執行個體的預備環境，並將其設定為連線到 (8) 中建立的異地備援次要資料庫。

注意

這些準備步驟不會影響實際執行環境中的應用程式。 這將會在讀寫模式中保持完整功能。

當準備步驟完成，預備環境即準備好進行真正的升級。 下圖說明了這些升級步驟：

1. 將實際執行環境中的主要資料庫設定為唯讀模式 (10)。 此模式可確保 實際執行資料庫 (V1) 在升級期間不會變更，因而防止 V1 和 V2 資料庫執行個體之間的資料分歧。

-- Set the production database to read-only mode
ALTER DATABASE [<Prod_DB>]
SET READ_ONLY

2. 透過中斷次要資料庫來終止異地複寫 (11)。 此動作會建立與主要資料庫完全同步但獨立的實際執行資料庫複本。 此資料庫將會升級。 下列範例會使用 Transact-SQL，但 PowerShell 同樣適用。

-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE [<Prod_DB>]
REMOVE SECONDARY ON SERVER [<Partner-Server>]

3. 針對 contoso-1-staging.azurewebsites.net、contoso-dr-staging.azurewebsites.net 以及預備主要資料庫執行升級指令 (12)。 資料庫變更將會自動複寫至預備次要資料庫。

如果升級順利完成，您現已準備好切換使用者至應用程式的 V2 版本。 下圖說明了涉及的步驟：

1. 啟用在主要區域 (13) 和備份區域 (14) 中 Web 應用程式的實際執行環境與預備環境之間的交換操作。 應用程式的 V2 現在會變成實際執行環境，並在備份區域中有備援複本。
2. 如果您不再需要 V1 應用程式 （15 和 16），則可以停止使用預備環境。

如果升級程序失敗（例如，升級指令發生錯誤），請確認是否預備環境處於不一致狀態。 欲將應用程式復原至升級前狀態，請還原實際執行環境中使用 V1 的應用程式。 下圖顯示了所需步驟：

1. 將實際執行環境中的主要資料庫設定為讀寫模式 (17)。 此動作會還原實際執行環境中的完整 V1 功能。
2. 執行根本原因分析和修復或移除預備環境 （18 和 19）。

此時，應用程式已完全正常運作，您可以重複升級步驟。

注意

回復不需要 DNS 變更，因為您沒有執行交換作業。

此選項的主要優點在於，可以同時升級應用程式和其異地備援複本，且不損害升級期間的商務持續性。

主要取捨在於，這需要每個應用程式元件的雙重備援，因此會產生更高的成本。 這也涉及到更複雜的工作流程。

摘要

本文所述的兩種升級方法在複雜性和成本上有所差異，但均著重於將使用者限制在唯讀操作的時間降至最低。 此時間長短會由升級指令的持續時間直接定義。 不取決於資料庫大小、您選擇的服務層級、網站設定，或您無法輕易控制的因素。 所有準備步驟都會與升級步驟解耦，且不會影響實際執行應用程式。 升級指令的效率是決定升級期間使用者體驗的重要因素。 因此，改善該體驗的最佳方式是盡量集中精力在讓升級指令更有效率上。

相關內容

• 商務持續性概觀。
• 使用作用中異地複寫建立可讀取的次要資料庫。
• 使用容錯移轉群組，針對多個資料庫啟用透明且協調的容錯移轉。
• 在 Azure App Service 中設定預備環境。
• 管理 Azure 流量管理員設定檔。