本文件介紹 Microsoft SQL Server 的災難復原 (DR) 策略，適用對象為負責設計災難復原策略並在 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) 中執行，如 Windows Server 容錯移轉叢集與 SQL 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 代理程式工作或連結的伺服器將移動到另一個執行個體。
您可以在不同的 Google Cloud 區域中建立 FCI 叢集節點。這個架構不僅能針對節點故障支援高可用性，也能在區域故障時提供高可用性。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 複製功能更為方便，因為它會透過 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 作業，同時存取主要資料庫和次要資料庫。在這種情況下，假如主要資料庫和次要資料庫互不同意同個資料項目的資料值，就會有資料不一致 ({0}核心分裂{/0}) 的問題。萬一主要資料庫在繼續執行的時候無法提供服務，這個架構就顯得格外重要，且還能接收寫入作業。假如無法提供服務的情況是間歇性網路分區引起的，則分區作業任何時間點都可以停止，而應用程式也許就能再次存取資料庫。如果此時發生容錯移轉程序，就可能會遺失在舊的主要資料庫上所做的變更，或者也有可能部分應用程式已開始在新的主要資料庫上運作，但其他部分還在存取舊的主要資料庫。
在容錯移轉期間，資料庫上的所有應用程式存取作業都將停用，以確保所有資料庫都不會發生狀態變更。而容錯移轉後，只有一個資料庫可用於寫入作業，也就是新的主要資料庫。
完成宣告
容錯移轉完成後，決策單位需要明確通知所有利益相關者程序已完成。凡是在完成後出現的問題都要視為單獨的事件，不應再歸於容錯移轉程序，而是屬於正常處理作業的一部分。這類問題可能是容錯移轉程序問題導致的後果，也可能是完全獨立的問題。但是，一旦完成容錯移轉，解決問題的方法可能就與容錯移轉進行期間解決問題的方法不同。
檢討報告分析和報表
為供日後參考及改善您的容錯移轉程序，請立即安排檢討報告分析，將重要層面的資料、發現和行動項目都記錄下來。
請在報表中彙整災難復原事件、根本原因，以及採取的所有動作。假如您目前導入相關監管要求，相關規定可能會要求您必須製作這份報表。
DR 測試和驗證
由於災難復原並不屬於日常作業的一部分，因此您必須定期測試 DR 解決方案，確保 DR 在實際需要時能正常運作。
測試的頻率取決於營運要求，並且會依資料庫、應用程式和企業而有所不同。此外，假如您對所選災難復原解決方案仰賴的系統進行變更，則環境變更 (例如網路設定變更和基礎架構元件更新) 應該會觸發災難復原測試。任何變更都可能導致災難復原解決方案失敗，或者可能需要調整災難復原程序。
您可以藉由啟動切換程序來手動進行測試，也可以按照 Chaos 程式設計一節中所述的 Chaos 程式設計方法來自動測試。如果採用手動測試，您就可以在預計會出現明顯的停機時間時，將業務影響降至最低。
收集明確定義的統計資料，也是測試工作中相當重要的一部分。需要考慮的一些重要統計資料如下：
- 實際復原時間：評估實際復原時間並將其與 RTO 比較。
- 實際復原點：觀察實際的復原點並將其與 RPO比較。
- 故障偵測時間：DBA 或營運團隊採行容錯移轉所花費的時間。
- 恢復啟動的時間：從偵測到故障後到啟動容錯移轉程序所花費的時間。
- 可靠性：容錯移轉程序的密切程度或與之相關的偏差程度如何？是否出現需要調查的意外問題，而且可能會導致復原策略發生變化？
您可能需要根據收集到的統計資料，進一步調整或改善容錯移轉程序，才能更有效地達成預期的 RPO 和 RTO。
範例：備份和還原 DR 策略
以下各節將概述備份與還原災難復原策略的範例。在這個情況下，系統會盡可能減少使用 SQL Server 可用性功能，以利介紹指定 DR 備份與還原策略時需要進行的工作，以及說明在偏自動化設定中較易忽略的層面。
用途
主要的 Always On 可用性群組位於地區 R1 並在該地區中執行。在地區 R2 中新增次要的 Always On 可用性群組，可提供額外的跨地區保護，且可在發生容錯移轉或切換目標時派上用場。
策略
災難復原策略以資料庫備份為基礎。進行初始完整備份之後，應緊接著執行後續差異備份。備份將在執行時套用至次要的 Always On 可用性群組。所有備份都會儲存在 Cloud Storage 值區中。
在本例中，從容錯移轉完成直到 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 可用性群組。
- 建立新的值區 B2，將完整備份做為基準，然後開啟新的主要可用性群組來進行應用程式存取。
- 開始進行差異備份。
在 R1 中，基本步驟如下：
- 將不再需要的值區 B1 刪除。
- 當 R1 中的 Always On 可用性群組再次可用時 (做為新的次要 Always On 可用性群組)，避免應用程式存取該群組，並移除資料庫中的所有資料或將資料重設為其初始 (空的) 狀態 (除非要求須使用新建的資料庫)。
- 從 R2 中新的主要 Always On 可用性群組套用完整備份，並在差異備份可用時立即套用 (儲存在值區 B2 中)。
可能的改善做法
要改善 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 的參考架構、圖表和最佳做法。歡迎瀏覽我們的雲端架構中心。