本文將介紹 Microsoft SQL Server 的災難復原 (DR) 策略，適合負責在 Google Cloud 上設計及實作災難復原機制的架構師和技術主管。 Google Cloud
資料庫可能會因為硬體或網路故障等各種原因而無法使用。為確保發生故障時仍可持續存取資料庫，系統會維護次要資料庫，做為主要資料庫的副本。將次要資料庫存放在不同的位置，這樣能提高主要資料庫無法使用時的資料庫可用機率。
如果主要資料庫無法使用，任務關鍵型應用程式會連線至次要資料庫，從最近一次已知的資料一致性狀態繼續運作，盡可能減少停機時間，或完全不停機，持續為使用者提供服務。
在主要資料庫發生故障時讓次要資料庫代為提供服務的過程就稱為「資料庫災難復原 (DR)」。次要資料庫會在主要資料庫無法使用時接手運作。次要資料庫最好與主要資料庫的狀態完全一致，或只缺少一小部分主要資料庫的近期交易，這樣在主要資料庫無法使用時，次要資料庫就能派上用場。
資料庫 DR 是企業客戶適用的基本功能。主要考量因素是關鍵任務應用程式的業務能持續運作。舉例來說，關鍵任務應用程式是指那些能產生收益 (電子商務)、提供持續可靠的服務 (航班或發電廠管理) 或支援維生功能 (患者監控) 的應用程式。在上述例子中，這些應用程式必須持續保持運作，因為它們執行的都是至關重要的關鍵任務。
大多數資料庫管理系統都提供災難復原功能，包括 Microsoft SQL Server。這份架構文件將說明如何在 Google Cloud中實作 SQL Server 提供的 DR 功能。
術語
以下各節介紹本文件中使用的術語。
一般 DR 架構
下圖示範的是一般 DR 架構拓撲。
在上圖中，應用程式會存取主要資料庫，而次要資料庫則處於待命狀態，並且建立主要資料庫狀態的鏡像。用戶端正在存取在「 Google Cloud」上執行的應用程式。
當主要資料庫無法使用，資料庫管理員或營運團隊就必須決定啟動災難復原程序。一旦啟動資料庫災難復原，應用程式將重新連線到次要資料庫。連線成功後，該應用程式即可再次為其用戶端提供服務。在理想情況下，應用程式可以能在最短的時間內透過次要資料庫再次運作，因此用戶端可能甚至不會遭遇到作業中斷。替代方法是等待主要資料庫恢復運作，而不是啟動災難復原程序。舉例來說，如果災害是間歇性的，解決問題可能比容錯移轉更快。
主要和次要資料庫
一或多個應用程式會存取主要資料庫，以便為應用程式的狀態管理提供永久服務。次要資料庫與主要資料庫相關，且包含主要資料庫的副本。理想情況下，次要資料庫的內容在任何時間點都會與主要資料庫的內容完全相同。不過大多數時候，為了套用主要資料庫所做的交易變更而產生的延遲，會導致次要資料庫的狀態比主要資料庫落後一點。視資料庫技術而定，您可以將多個次要資料庫與主要資料庫建立關聯。SQL Server 支援將多個次要資料庫與主要資料庫相關聯。
災難復原
當主要資料庫無法使用，DR 會將次要資料庫的角色變更為主要資料庫庫。如有多個次要資料庫，您可手動選擇其中一個資料庫，或由系統根據偏好的容錯移轉清單來擇一使用。應用程式必須重新連線到新的主要資料庫才能繼續存取其狀態。如果新的主要資料庫庫與先前主要資料庫的最後已知狀態不同步，則應用程式會從過去的狀態 (也稱為「閃回 (flashback)」) 開始。
每個主要資料庫必須隨時都有至少一個次要資料庫。因此每次災難復原後，請務必設定新的次要資料庫，以便因應日後的災難復原情況。
容錯移轉、切換和備用
有多種情況可能會需要變更主要資料庫和次要資料庫之間的角色，例如：
- 容錯移轉：將次要資料庫的角色變更為新的主要資料庫，並將所有應用程式連線到該資料庫的過程。容錯移轉是由主要資料庫無法使用所觸發，因此並非有意為之。您可以將容錯移轉設為自動或手動觸發。
- 切換：與容錯移轉相反，從主要資料庫切換為次要數據庫 (新的主要資料庫) 的切換行為是刻意觸發，主要是為了進行初始化測試和定期維護。透過定期切換來測試 DR 系統是否能正常運作，以確保災難復原的持續可靠性。
- 備用：備用程序是指主要資料庫修復之後，讓新的主要資料庫再變回次要資料庫的逆向過程。備用作業是刻意觸發，以便在啟動容錯移轉或切換程序前重新建立狀態。這不是必要程序，您可以根據災難復原要求 (例如本地性或可用資源) 來決定是否執行這項作業。
Google Cloud 區域和可用區
資料庫等資源位於Google Cloud 可用區和區域，每個可用區都屬於一個區域。可用區是單點故障網域。 建議您在區域內的多個可用區中，部署高可用性且容錯的資源。
為避免整個地區的服務中斷，請針對災難復原建立多地區策略。舉例來說，主要資料庫位於某個區域，而對應的次要資料庫則位於另一個區域。
主動模式：主動/被動 (active-passive) 和雙主動 (active-active)
主要資料庫是開放讀寫作業 (DML 作業) 的資料庫，以便存取該資料庫的應用程式能管理其狀態。主要資料庫稱為「主動」資料庫。對應的次要資料庫會複製主要資料庫，屬於被動狀態，但任何應用程式都無法存取次要資料庫來進行狀態變更作業。容錯移轉或切換後，次要資料庫將成為新的主要資料庫並成為主動資料庫。
如果資料庫技術支援主要資料庫和次要資料庫都是主動狀態，這又稱為「雙主動模式」。在這種情況下，應用程式想連線到主要資料庫或次要資料庫都沒問題，因為這兩個資料庫都可用於狀態管理。如果只有一個主動資料庫無法使用，則雙主動模式下的災難復原不需要進行容錯移轉。假使有一個主動資料庫無法使用，另一個主動資料庫會持續提供服務。不過，雙主動模式並不在本文的討論範圍，因為 SQL Server 不支援此模式。
待命模式：熱待命、暖待命、冷待命及無待命
如要讓主要資料庫成為主動資料庫，其必須處於執行狀態且能夠執行 DML 陳述式。次要資料庫則不需要處於執行狀態 (可以關閉)。但要是次要資料庫未執行，災難復原所需的時間就會增加，因為新的主要資料庫必須先進入執行狀態，才能獲取新主要資料庫的角色。
次要資料庫有以下幾種不同的設定方式：
- 熱待命：次要資料庫已啟動並正在執行，且可供用戶端連線。一旦主要資料庫中有最新的可用變更，一律立即套用。
- 暖待命：次要資料庫已啟動並正在執行，但不一定會立即套用所有來自主要資料庫的變更。
- 冷待命：次要資料庫未執行。次要資料庫必須先啟動，然後才會同步到最新的可用狀態。
- 無待命：必須先安裝資料庫軟體，緊接著啟動資料庫，然後才能套用來自主要資料庫的所有變更。這個模式是成本花費最少的模式，因為不需要用到時也不會一直消耗資源，但與其他模式相比，就要花最長的時間才能成為新的主要資料庫。
DR 策略
在以下各節中，我們將介紹 Microsoft SQL Server 支援的 DR 策略。
復原策略維度
在選擇或導入資料庫災難復原策略時，您必須考量幾個重要的維度。每個維度都會有一個範圍，而災難復原策略的行為和預期結果則取決於您在該範圍上指定的值。這類關鍵維度如下：
- 復原點目標 (RPO)： 應用程式因為重大事件而可能遺失資料的可接受時間長度上限。這個維度依資料的使用方式而有所不同。RPO 可以用時間長度 (秒、分或小時) 表示，從主要資料庫無法使用時算起，也可以用可識別的處理狀態表示 (上次完整備份或上次增量備份)。無論如何指定 RPO，災難復原策略都必須採用特定指標，以符合 RPO 要求。其中，最嚴苛的要求是「最後修訂的交易」，這表示不管發生什麼情況，次要資料庫都不能遺失主要資料庫的任何資料。
- 復原時間目標 (RTO)。 應用程式可離線的最長可接受時間。這個值通常會指定為較大的服務水準協議的一部分。RTO 通常以主要資料庫無法使用的時間長度表示，例如應用程式必須在 5 分鐘內完全運作。最嚴苛的情況是立即恢復運作，這樣應用程式使用者才不會注意到發生災難復原。
- 單一故障域。請根據災害復原需求，自行判斷區域是否為單點故障網域。如果某個區域是您的單一故障點網域，則必須設定災難復原機制，讓實際設定涉及兩個以上的區域。如果主要資料庫所在的區域發生故障，不同區域的次要資料庫就會成為新的主要資料庫。如果假設單點故障網域是可用區，則可以在單一區域內的可用區之間設定災難復原機制。如果區域發生故障，災難復原將使用第二個區域，並讓其中的新主要資料庫提供服務。
決定這些重要維度，就是要在成本和品質之間做出取捨。 RTO 和 RPO 越低，使用的現有資源就越多，因此災難復原解決方案的成本可能越高。在以下各節中，我們將討論幾種不同的 DR 策略，這些策略中採用的值是以 Microsoft SQL Server 資料庫環境中的維度為基礎。
SQL Server 的 DR 策略
業務持續性和資料庫復原 - SQL Server 一文說明可用性功能，可協助您實作災難復原策略。
初步
SQL Server 可在 Windows 和 Linux 上執行，不過，Linux 不支援所有可用性功能。SQL Server 有多個版本，但並非每個版本都提供所有可用性功能。
SQL Server 會將執行個體與資料庫做區別，其中，執行個體是執行 SQL Server 軟體，而資料庫則是指由 SQL Server 執行個體管理的一組資料集。
Always On 可用性群組
Always On 可用性群組提供資料庫層級的保護功能。可用性群組具有兩組以上的備用資源。其中一個備用資源是主要備用資源，具備讀取和寫入權限，其餘備用資源則是次要備用資源，可提供讀取權限。每個資料庫副本都是由獨立的 SQL Server 執行個體管理。可用性群組可包含一或多個資料庫。 可用性群組可納入的資料庫數量，以及支援的次要副本數量，取決於 SQL Server 版本。可用性群組中的所有資料庫都會同時經歷同樣的生命週期變更。可用性群組採用的是主動/被動模式，因為只有主要資料庫支援寫入存取。
發生容錯移轉時，次要副本會成為新的主要副本。 由於可用性群組包含獨立的 SQL Server 執行個體，因此交易記錄中擷取的所有作業都會在副本中提供。您必須手動同步處理交易記錄檔中未擷取到的所有變更，例如 SQL Server 執行個體層級的登入作業或 SQL Server 代理程式工作。如要提供資料庫層級的保護功能和 SQL Server 執行個體保護功能，您必須設定容錯移轉叢集執行個體 (FCI)。稍後在Always On 容錯移轉叢集一節中將會說明這個部署架構。
您可以使用事件監聽器，避免應用程式遭到角色變更。事件監聽器支援連線到可用性群組的應用程式。應用程式不知道哪個 SQL Server 執行個體會在任何一個時間點管理主要資料庫或次要備用資源。事件監聽器要求用戶端至少使用 3.5 版 (含更新項目) 或 4.0 以上版本的 .NET，如業務持續性和資料庫復原 - SQL Server 一節中所述。
可用性群組仰賴基礎抽象層來提供相關功能。可用性群組會在 Windows Server 容錯移轉叢集 (WSFC) 中執行，如「搭配 SQL Server 使用 Windows Server 容錯移轉叢集」一文所述。執行 SQL Server 執行個體的所有節點都必須屬於同一個 WSFC。
交易會從主要資料庫傳送至所有次要副本。交易的傳送模式有兩種：同步和非同步。 您可以分別設定每個副本，使用其中一種模式。在同步傳送模式中，只有當主要資料庫上的交易在所有同步連結的次要副本上都成功時，交易才會成功。在非同步模式中，即使並非所有次要副本都已套用交易，主要資料庫上的交易仍可成功。
您選擇的傳送模式會影響潛在的 RTO、RPO 和待命模式。舉例來說，如果交易以同步模式傳送到所有備用資源，則所有備用資源都會處於完全相同的狀態。由於所有備用資源都完全同步，因此符合最嚴苛的 RPO (最近的交易) 要求。次要備用資源屬於熱待命，因此任何備用資源都可以立即做為主要資料庫。
容錯移轉可以自動或手動執行。如果所有備用資源都已完全同步處理，則可進行自動容錯移轉。在前述範例中，因為所有備用資源始終保持同步處理，因此可採用自動容錯移轉。
下圖顯示單一區域中的 Always On 可用性群組。
矩形的橫跨區域代表可用性群組。本圖僅為示意圖，用來表示所有資料庫都屬於同一個可用性群組。可用性群組不是雲端資源，因此不會導入到節點或任何其他類型的資源。
Always On 容錯移轉叢集執行個體
如要避免節點故障，您可以使用容錯移轉叢集執行個體 (FCI)，而不要採用獨立的 SQL Server 執行個體。有兩個以上的節點用來執行 SQL Server 執行個體來管理資料庫 (主要資料庫或次要資料庫) 的節點。管理資料庫的節點就會形成容錯移轉叢集。叢集中的一個節點正在主動執行 SQL Server 執行個體，而其他節點並未執行 SQL Server 執行個體。執行 SQL Server 執行個體的節點發生故障時，叢集中的另一個節點將會啟動 SQL Server 執行個體，從而接管資料庫的管理作業 (節點容錯移轉)。這個自動啟動 SQL Server 執行個體的程序提供了高可用性功能。
FCI 叢集顯示為單一單元，存取叢集的用戶端不會發覺節點之間的容錯移轉，除非發生短暫無法使用的情況。發生節點容錯移轉時並不會遺失任何資料。在失敗的 SQL Server 執行個體中執行的所有內容都會移到同一叢集中的其他 SQL Server 執行個體。例如，SQL Server 代理程式工作或連結的伺服器將移動到另一個執行個體。
FCI 叢集節點可設定在不同 Google Cloud 區域。這個架構不僅能針對節點故障支援高可用性，也能在區域故障時提供高可用性。DR 部署替代方案一節將討論這項策略的部署範例。
即使由不同的節點管理並共用相同的資料庫，FCI 叢集的節點之間也不需要有任何共同的儲存空間。SQL Server 使用儲存空間直接存取 (S2D) 功能來管理專用節點磁碟上的資料庫。詳情請參閱設定 SQL Server 容錯移轉叢集執行個體。
下圖顯示上一節的「Always On 可用性群組」範例，但使用 FCI 而非獨立 SQL Server 執行個體。每個 FCI 都有一個主動的 SQL Server 執行個體負責管理資料庫。
與可用性群組的情況相同，FCI 會以矩形表示。 這僅為說明用途，表示節點都屬於同一個 FCI。FCI 不是雲端資源，因此不會在節點或任何其他類型的資源中實作。
詳情請參閱 Always On 叢集執行個體 (SQL Server)。
分散式可用性群組
分散式可用性群組是特殊類型的可用性群組。分散式可用性群組橫跨兩個可用性群組，分別代表主要可用性群組角色和次要可用性群組角色，而且能以同步及非同步模式，將交易轉送從主要可用性群組轉送到次要可用性群組。
即使每個可用性群組都有自己的主要資料庫，但這並不是雙主動部署。只有主要可用性群組的主要資料庫才能接收寫入作業。次要可用性群組的主要資料庫稱為轉寄站。轉寄站從主要可用性群組接收交易，並將這些交易轉送到次要可用性群組的次要資料庫。從主要可用性群組容錯移轉到次要可用性群組時，新的主要可用性群組的主要資料庫將可供寫入存取。
主要和次要可用性群組不必位於同樣的位置，而且也不一定要在同樣的作業系統中。但是每個可用性群組都必須安裝一個事件監聽器。分散式可用性群組本身沒有事件監聽器。分散式可用性群組不需要兩個可用性群組位於相同的 WSFC。SQL Server 功能包含所有讓分散式可用性群組運作所需的功能，不需要額外安裝基礎元件。
分散式可用性群組剛好橫跨兩個可用性群組。可用性群組可以是兩個分散式可用性群組的一部分，因此能支援不同的拓撲。其中一種是從可用性群組到多個位置的可用性群組，以菊花鏈拓撲的形式。另一種是樹狀拓撲，其中的主要可用性群組屬於兩個不同且獨立的分散式可用性群組的一部分。
分散式可用性群組是跨作業系統導入災難復原的主要方式。舉例來說，您可以在 Windows 上設定主要可用性群組，在 Linux 上設定對應的第二個可用性群組，這兩個可用性群組將構成分散式可用性群組。
下圖顯示屬於分散式可用性群組一部分的兩個可用性群組。
可用性群組 1 是主要可用性群組，可用性群組 2 是次要可用性群組。
與 FCI 的情況一樣，分散式可用性群組以矩形表示。本圖僅為示意圖，用來表示可用性群組全都屬於同一個分散式可用性群組。與可用性群組不同的是，分散式可用性群組並不是雲端資源，因此不會導入到節點或任何其他類型的資源。
詳情請參閱分散式可用性群組。
記錄傳輸
如果 RTO 和 RPO 不那麼嚴格 (低 RTO 和/或近期 RPO)，交易記錄運送就是 SQL Server 可用性功能，因為主要資料庫和次要資料庫之間的狀態差異會顯著擴大。交易記錄檔包含許多狀態變更，因此狀態差異較大。此外，交易記錄檔採非同步傳輸且必須完整套用到次要資料庫，所以延遲時間的差異也很明顯。
交易記錄檔由主要資料庫建立並備份 (例如備份到 Cloud Storage)。所有交易記錄檔都會複製並套用到每一個次要資料庫。由於次要資料庫會落後主要資料庫，因此處於暖待命模式。您必須將交易記錄檔未擷取到的物件和變更手動套用到次要資料庫，才能建立完整的同步作業而不遺失任何資料。
SQL Server 代理程式能自動執行建立、複製和套用交易記錄檔的整個程序。您必須為每個資料庫分別設定記錄傳輸功能。如果可用性群組管理多個資料庫，您就必須按資料庫數量設定對應的記錄傳輸程序。
萬一發生故障，您必須手動啟動災難復原程序，因為 SQL Server 不支援自動化執行災難復原。此外，事件監聽器不會從主要資料庫和次要資料庫擷取用戶端存取權。發生容錯移轉時，用戶端必須能夠自行處理資料庫的角色變更 (從次要角色變更為新的主要角色)，方法是在災難復原後連線至新的主要角色。此外，您可以建構獨立於 SQL Server 執行個體的個別抽象層，例如浮動 IP 位址最佳做法中所述的浮動 IP 位址。
由於記錄傳輸是手動作業，因此您可以特意將複製的記錄檔延遲套用到次要資料庫 (相較於立即套用變更的可用性群組和分散式可用性群組)。其中一個可能的用途是防止主要資料庫的資料修改錯誤套用至次要資料庫，直到解決資料修改錯誤為止。這樣一來，還沒有套用到資料修改錯誤的次要資料庫就能在相關錯誤修正之後才成為主要資料庫，緊接著就可以恢復正常運作。
與分散式可用性群組的情況一樣，記錄傳輸功能適用於跨平台解決方案，例如主要資料庫在 Linux 上執行，而次要資料庫則在 Linux 和Windows 中執行。
下圖顯示具有記錄傳輸功能的跨平台部署。請注意，這個拓撲中沒有像分散式可用性群組的跨地區常用設定。
可用性群組分別位於不同的地區，其中一個在 Linux 上執行，另一個在 Windows 上執行。
如要進一步瞭解 SQL Server 記錄傳輸，請參閱記錄傳輸簡介 (SQL Server)。
結合 SQL Server 可用性功能
您可以依不同的組合來部署 SQL Server 可用性功能。舉例來說，在上述用途中，記錄檔傳送作業搭配使用安裝在不同作業系統上的不同可用性群組。
以下列出 SQL Server 可用性功能的幾種可能組合：
- 在安裝於同一個作業系統的可用性群組之間使用記錄傳輸功能。
- 讓主要可用性群組使用含次要可用性群組且只使用 SQL Server 獨立式執行個體的 FCI。
- 在附近的地區間使用分散式可用性群組，並在橫跨不同大陸的地區使用記錄傳輸。
以上只是 SQL Server 可用性功能的一些可能運用組合。
SQL Server 的可用性功能具備靈活性，可讓您根據相關所述規定來微調災難復原策略。
SQL Server 複製
雖然 SQL Server 複製功能一般並不視為可用性功能，但本節將概要說明如何將這項功能運用於災難復原程序。
複製功能支援建立和維護資料庫的備用資源。不同類型的 SQL Server 代理程式能共同擷取變更、傳輸擷取的變更，以及將這些變更套用到備用資源。這個過程為非同步處理，且備用資源通常會略為落後正在複製的資料庫。
舉例來說，您可以擁有正式環境資料庫的副本。就災難復原而言，實際工作環境資料庫是主要資料庫，副本則是次要資料庫。SQL Server 複製功能不知道資料庫在災害復原情境中扮演不同角色。因此，複製功能並沒有支援災難復原程序的作業 (例如角色變更)。由於沒有用戶端存取抽象化，災難復原程序必須與 SQL Server 功能分開實作，並由實作的機構執行。
備份檔案傳輸
備份檔案傳輸是另一種災難復原導入策略。其中一個設定和持續更新次要資料庫的標準方法是對主要資料庫進行初始完整備份，之後再進行增量備份。所有增量備份都會按正確的順序套用至次要資料庫。這種方式有很多不同的運用做法，具體取決於增量備份的頻率，還有備份檔案的儲存空間位置 (global 位置或實際在位置之間複製)。
從主要資料庫複製狀態變更至任何次要資料庫時，這項策略不會涉及任何 SQL Server 可用性功能。這項功能不會使用記錄檔出貨時的 SQL Server 代理程式。
詳情請參閱範例：備份和還原 DR 策略一節。
與前一節討論的複製方法相比，複製和備份檔案傳輸的共同點是，災難復原程序是在 SQL Server 功能集外部和獨立實作。就傳送擷取的變更而言，SQL Server 複寫功能更方便，因為這部分會透過 SQL Server 代理程式自動實作。
有關資料庫生命週期和應用程式生命週期互動的注意事項
資料庫容錯移轉並非完全區隔或獨立於存取該資料庫的應用程式。原則上，容錯移轉有兩種情況。
第一種情況：資料庫進行容錯移轉時，應用程式保持運作。從主要資料庫無法使用算起，一直到新主要資料庫開始運作，應用程式完全無法存取資料庫。現有連線失敗且也未建立新的連線。在此期間，應用程式無法為其用戶端提供服務，至少無法提供需要存取資料庫的相關服務。應用程式必須識別新的主要資料庫何時能使用，以便儘快恢復正常處理程序。
應用程式可能具有資料庫以外的狀態，例如主記憶體快取狀態。而該應用程式會確保快取與新的主要資料庫保持一致 (同步)。如果在容錯移轉期間沒有任何交易遺失，快取項目可能就是一致的，因此不必做進一步的維護。但要是容錯移轉間有交易 (資料) 遺失，則快取項目可能就與新主要資料庫的快取不一致。類似的討論內容適用於共用狀態，舉例來說，資料庫內某些資料也屬於佇列訊息的一部分，或檔案系統中的檔案。這部分的資料一致性與資料庫災難復原並無直接關係，因此不在本文件的討論範圍內。
第二種情況：一或多個應用程式可能與主要資料庫同時無法使用。舉例來說，如果某個區域離線，在該區域執行的應用程式系統就會無法使用，如同該區域的主要資料庫。在這種情況下，除了主要資料庫系統，您還必須一併復原應用程式。您需要啟動資料庫災難復原程序，以及類似的應用程式復原程序。恢復的應用程式必須連線到新的主要資料庫，並重新進行浮動 IP 位址等相關設定。請注意，應用程式的復原作業不在本文的討論範圍。
災難復原的備份和還原作業之間的關係
備份資料庫與資料庫災難復原作業無關，且彼此正交。資料庫備份的目的是為了還原一致的狀態，例如在資料庫遺失或損毀時，或是因應用程式故障或錯誤而必須還原先前的狀態。
下一節討論如何將備份當做一種可能的資料庫災難復原導入機制。在這個情況下，您要將備份檔案複製到次要資料庫的位置，以便還原次要資料庫。但是，備份檔案並非災難復原的先決條件，上文中有關可用性功能的討論也介紹了替代方案。
高可用性和災難復原
高可用性和災難復原的共通點在於，它們都能針對資料庫無法使用的狀況提供因應的解決方案。如果主要資料庫無法使用，則次要資料庫就會成為一致且可用的新主要資料庫。
高可用性和災難復原的差異在於單一故障點網域。高可用性可解決區域內的服務中斷問題，例如單一可用區或節點故障時。高可用性解決方案會在相同區域的其他可用區中提供新的主要資料庫。此外，高可用性可解決節點故障問題，而不僅是資料庫故障。如果執行 SQL Server 執行個體的節點發生故障，系統會提供新的節點，執行新的 SQL Server 執行個體 (請參閱「Always On 容錯移轉叢集執行個體」一節的討論)。
災難復原的範圍涵蓋至少兩個地區，可解決整個區域無法使用的情況。災難復原功能可在不同區域提供新的主要資料庫。
SQL Server 高可用性功能同時支持高可用性和災難復原這兩項解決方案。單個可用性群組的範圍可橫跨地區內的不同區域，以及地區本身。可用性群組可包含容錯移轉叢集執行個體，以便因應高可用性問題。
SQL Server 可在一個區域內建立可用性群組，以因應高可用性和可用區故障，並結合跨區域的記錄傳送功能，解決災難復原問題。
DR 部署替代方案
在以下各節中，除了目前為止討論的內容之外，我們還會介紹幾項可能的災難復原拓樸。這些拓撲能滿足不同的 RPO 和 RTO 要求。這份清單僅列出部分範例。
地區內的 DR 和高可用性
這項部署是包含 FCI 的可用性群組的變化版本，位於一個由三個區域組成的地區內。在這種情況下，可用區會視為單一故障點網域。
相較於前文所述的部署，每個 FCI 是由三個節點組成，其中每個節點都在不同的區域中執行。這種配置的好處是，即使其中任何一個或兩個區域發生故障，也不需要啟動災難復原程序。
下列圖表顯示這項設定。
FCI 橫跨所有區域，且每個 FCI 都有一個執行中的 SQL Server 執行個體正在存取相應的資料庫。還有兩個 SQL Server 執行個體並未在各個 FCI 中執行，因此當區域故障時即可加以啟動。資料庫會顯示在各個可用區，因為每個資料庫都會使用特定 FCI 中所有節點的磁碟。為求清楚，畫面不會顯示應用程式。
地區內 DR：跨地區的可用性群組
在這個情況下，可用性群組會在 Windows Server 容錯移轉叢集上執行，並且橫跨兩個地區。一般認為區域可能會有單點故障網域的問題。
下圖說明了這項設定。
為解決潛在的延遲問題，您可以設定 R1 區域內的副本使用同步交易傳播，而 R2 區域內的副本則使用非同步交易傳播。
地區內 DR：備份檔案傳輸
這個情況下將使用備份檔案傳輸。兩個地區的兩個可用性群組會互相連結。每個可用性群組都有各自的備用資源來同步接收交易資料，因此各地區的次要備用資源都處於熱待命設定狀態。
下圖說明了這項設定。
但是，兩個可用性群組會透過備份檔案傳輸進行連線。可用性群組 AG1 是主要可用性群組，可用性群組 AG2 是次要可用性群組。當備份檔案可供次要可用性群組使用時，就會套用到該群組。我們會在下一節「範例：備份和還原 DR 策略」中詳加說明。
雙元位置和三元位置拓撲
如果只有兩個資料庫 (主要資料庫和次要資料庫分別位於不同區域)，在從主要資料庫容錯移轉後，新主要資料庫開始運作到新次要資料庫準備就緒前，會有一段時間處於未受保護的狀態。要是新的主要資料庫在次要資料庫尚未執行前就無法使用，就會發生硬停機，只有等到新的主要資料庫建立完成後才會恢復。以上情況同樣適用於可用性群組。
在第三個位置執行執行另一個次要資料庫或可用性群組，有助避免容錯移轉後有段期間不受保護。這項設定必須確保兩個次要資料庫之一能保留做為次要資料庫，並重新分配給新的主要資料庫，以免遺失任何資料。以上情況同樣適用於可用性群組。
DR 生命週期
無論您選擇哪種災難復原解決方案，都適用常見的生命週期步驟。
在實際的災難復原情況中，所有利害關係人 (應用程式擁有者、營運團隊和資料庫管理員) 都必須在場，並積極參與管理災難復原作業。利害關係人必須決定決策授權 (有時稱為司儀) 和遵循的決策程序。此外，利害關係人必須就術語和溝通方式達成共識。
決定啟動容錯移轉程序
除非系統自動啟動容錯移轉，否則利害關係人必須決定是否啟動容錯移轉。決定啟動容錯移轉時，各利害關係人必須密切協調。
啟動容錯移轉的程序取決於幾項因素，尤其需要考量導致主要資料庫無法使用的根本原因。
如果災難復原程序所需時間超出預期，導致主要資料庫無法使用，容錯移轉就會造成負面影響。首先，您必須評估還原主要資料庫是否可行。
對於災難復原策略的測試越周全，除了越能快速完成導入作業，在做決策時因需要考慮的不確定性比較少，所以啟動容錯移轉的程序也會更容易。
執行容錯移轉程序
理想情況下，應定期測試容錯移轉程序，讓各個利害關係人熟悉相關流程。
決策授權單位必須瞭解所有進行中的步驟，以及所有意外問題。決策授權單位會啟動容錯移轉程序，而利害關係人則負責支援決策授權單位。
您應該保留檢討報告分析和容錯移轉程序的改善統計資料，包括活動持續時間、出現的問題，以及容錯移轉程序步驟中的任何混淆。
缺少保護
如果您只有一個次要資料庫，從新主要資料庫可供使用且能正常運作，直到設定新的次要資料庫這段期間，將不會有任何 DR 保護。如果在這段時間內無法使用，可能會導致硬性停機，因為無法容錯移轉至其他資料庫。如果出現這種情況，則必須設定另一個主要資料庫，RPA 是根據可用備份重建的最後一個點。
除非設定災難復原策略以便全程提供保護，否則每個利益相關者都必須知道設定或環境設定變更時會有段時間將缺少保護，因而必須採取額外的預防措施。
如果應用程式能延到新的次要資料庫已啟動並執行，再來存取新的主要資料庫，就能避掉這段不受保護的期間。一旦套用了主要資料庫的變更，主要資料庫就可供應用程式使用。雖然這種方法能確保應用程式任何時候都受到 DR 保護，但災難復原程序也可能會延遲完成。
避免核心分裂情況
請特別注意，應用程式不能透過發出 DML 作業，同時存取主要資料庫和次要資料庫。在此情況下，主要資料庫和次要資料庫對同一資料項目的資料值不一致，導致資料不一致 (腦裂)。如果主要資料庫持續運作並可接收寫入作業，但無法使用，這種架構就特別重要。假如無法提供服務的情況是間歇性網路分區引起的，則分區作業任何時間點都可以停止，而應用程式也許就能再次存取資料庫。如果此時發生容錯移轉程序，就可能會遺失在舊的主要資料庫上所做的變更，或者也有可能部分應用程式已開始在新的主要資料庫上運作，但其他部分還在存取舊的主要資料庫。
在容錯移轉期間，資料庫上的所有應用程式存取作業都將停用，以確保所有資料庫都不會發生狀態變更。而容錯移轉後，只有一個資料庫可用於寫入作業，也就是新的主要資料庫。
完成宣告
容錯移轉程序完成後，決策機構必須明確通知所有利害關係人程序已完成。完成後出現的任何問題都必須視為獨立事件，不再屬於容錯移轉程序，而是屬於一般處理程序。問題可能是容錯移轉程序發生問題所致，也可能完全是獨立問題。不過，在容錯移轉程序完成後解決問題的方法，可能與容錯移轉程序執行期間的解決方法不同。
檢討報告分析和報表
為供日後參考及改善您的容錯移轉程序，請立即安排檢討報告分析，將重要層面的資料、發現和行動項目都記錄下來。
請在報表中彙整災難復原事件、根本原因，以及採取的所有動作。假如您目前導入相關監管要求，相關規定可能會要求您必須製作這份報表。
DR 測試和驗證
由於災難復原並不屬於日常作業的一部分，因此您必須定期測試 DR 解決方案，確保 DR 在實際需要時能正常運作。
測試的頻率取決於營運要求，並且會依資料庫、應用程式和企業而有所不同。此外，假如您對所選災難復原解決方案仰賴的系統進行變更，則環境變更 (例如網路設定變更和基礎架構元件更新) 應該會觸發災難復原測試。任何變更都可能導致災難復原解決方案失敗，或者可能需要調整災難復原程序。
您可以手動啟動切換程序進行測試，也可以按照「混沌工程」一文所述的混沌工程方法，自動執行測試。如果預期會出現明顯的停機時間，手動測試可將對業務的影響降到最低。
收集明確定義的統計資料，也是測試工作中相當重要的一部分。需要考慮的一些重要統計資料如下：
- 實際復原時間：評估實際復原時間並將其與 RTO 比較。
- 實際復原點：觀察實際的復原點並將其與 RPO比較。
- 故障偵測時間：DBA 或營運團隊採行容錯移轉所花費的時間。
- 恢復啟動的時間：從偵測到故障後到啟動容錯移轉程序所花費的時間。
- 可靠性：容錯移轉程序的密切程度或與之相關的偏差程度如何？是否出現需要調查的意外問題，而且可能會導致復原策略發生變化？
您可能需要根據收集到的統計資料，進一步調整或改善容錯移轉程序，才能更有效地達成預期的 RPO 和 RTO。
範例：備份和還原 DR 策略
以下各節將概述備份與還原災難復原策略的範例。這個情境會盡量減少使用 SQL Server 可用性功能，藉此說明指定 DR 備份與還原策略所需的工作量，並討論在更自動化的設定中看不到的層面。
用途
主要 Always On 可用性群組位於 R1 區域，且運作中。 在 R2 區域中新增次要 Always On 可用性群組，以提供額外的跨區域保護，並做為容錯移轉或切換目標。
策略
災難復原策略以資料庫備份為基礎。進行初始完整備份之後，應緊接著執行後續差異備份。備份將在執行時套用至次要的 Always On 可用性群組。所有備份資料都會儲存在 Cloud Storage bucket 中。
在本例中，從容錯移轉完成直到 R1 中的新次要 Always On 可用性群組開始運作之前，R2 中的新主要 Always On 可用性群組會有一小段時間處於主動狀態，並且不受保護。
由於每個地區的 Always On 可用性群組同樣有資格做為實際工作環境中的 Always On 可用性群組，因此不必採行備用作業。
RTO 和 RPO
本例中的 RPO 定義為最多 60 分鐘，因此系統每 60 分鐘會進行一次差異備份。
RTO 未明確設為持續時間，但請儘可能縮短 (建議最好設為立即)。次要可用性群組必須設為熱待命。如果是熱待命，系統會立即套用所有備份，這樣容錯移轉在套用備份時就不會延遲。
高階 DR 策略
以下各節將概述 DR 策略，並提供精簡版的基本步驟。
初始設定
- 在 R2 區域中建立次要 Always On 可用性群組。
- 禁止應用程式存取次要可用性群組，以免不小心出現核心分裂的情況。
- 在 Cloud Storage 中建立備份檔案值區 B1，以包含 R1 中 Always On 可用性群組的初始完整備份，以及 R1 中 Always On 可用性群組的後續每小時差異備份。您必須建立差異備份的正確順序，以便套用備份至次要可用性群組的程序能推斷出正確的順序。其中一種做法是利用命名慣例，在不同的檔名中使用日期和時間，藉此建立正確的時間順序。
啟動策略
- 將完整備份套用至 R2 區域的次要 Always On 可用性群組。
- 當差異備份可用時，立即將這些備份套用至 R2 中的次要 Always On 可用性群組。為達到 RTO 要求，必須立即套用。
- 套用初始完整備份及所有增量備份後，次要 Always On 可用性群組就已準備就緒。
- 從主要可用性群組切換到次要可用性群組，藉此測試 DR 策略。測試期間至少應有一個增量備份。
容錯移轉或切換案例
在 R2 中，基本步驟如下：
- 確保將最新的差異備份套用至 R2 中的次要 Always On 可用性群組。
- 將 R2 指定為新的主要 Always On 可用性群組。
- 建立新的 bucket B2，完整備份做為基準，並開放新的主要可用性群組供應用程式存取。
- 開始進行差異備份。
在 R1 中，基本步驟如下：
- 移除 B1 值區，因為不再需要使用該值區。
- 當 R1 中的 Always On 可用性群組再次可用時 (做為新的次要 Always On 可用性群組)，避免應用程式存取該群組，並移除資料庫中的所有資料或將資料重設為其初始 (空的) 狀態 (除非要求須使用新建的資料庫)。
- 在 R2 中套用新的 Always On 主要可用性群組完整備份，並在差異備份可用時立即套用 (儲存在 B2 bucket 中)。
可能的改善做法
要改善 DR 策略，其中一個可能的做法是避免在容錯移轉或切換後進行完整備份，同時要能快速設定新的次要可用性群組。建議每週進行一次完整備份 (而不是一個完整備份加上後續的差異備份)，並建立每週值區，用來容納當週的完整備份及所有後續差異備份。新的主要可用性群組必須只在容錯移轉 (而非完整備份) 後建立差異備份，而且應將這些差異備份新增到值區。新的次要可用性群組只套用當週值區中的所有備份。如果採用這個每週備份與值區的做法，您將需要導入清除策略來移除過時的備份。
另一個改善做法是將新的次級可用性群組視為舊的主要可用性群組。如果資料庫存在且在恢復運作後可正常運作，則還原至上次差異備份的時間點，可避免必須從上次完整備份完全還原資料庫，如「將 SQL Server 資料庫還原至特定時間點 (完整復原模式)」一文所述。這種情況可減少新主要可用性群組不受保護的時間，並降低工作量。
正式環境最佳做法
這個解決方案並未指定 Always On 可用性群組中的 SQL Server 執行個體是獨立或 FCI 執行個體。您必須在實作之前決定使用的執行個體類型。
從容錯移轉後到新的次要 Always On 可用性群組開始運作之前，DR 會有一段時間不受保護。您應在第三個區域中設定第三個 Always On 可用性群組。
此外，您應導入監控程序，以利偵測任何故障或錯誤；這對於災難復原解決方案能否正常運作至關重要，不過監控部分不在本文的討論範圍。
後續步驟
- 設定 SQL Server Always On 可用性群組。
- 在 Compute Engine 上部署多個子網路 SQL Server 2016 Always On 可用性群組。
- 設定 SQL Server 容錯移轉叢集執行個體。
- 執行 Windows Server 容錯移轉叢集。
- 如何為 .NET 應用程式啟用 Cloud Logging、Cloud Monitoring 和 Error Reporting
- 安裝 Cloud Monitoring 代理程式。
- 探索 Google Cloud 的參考架構、圖表和最佳做法。歡迎瀏覽我們的 Cloud Architecture Center。