部署 Microsoft SQL Server 以便進行多區域災難復原

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

瞭解災難復原

在 Google Cloud中，災難復原 (DR) 是指提供處理作業的持續性，尤其是在區域發生故障或無法存取時。對於資料庫管理系統等系統，您可以透過在至少兩個地區部署系統來實施 DR。在這種設定下，如果某個區域無法使用，系統仍可繼續運作。

資料庫系統災難復原

在主要資料庫執行個體發生故障時，讓次要資料庫提供服務的過程就稱為「資料庫災難復原」 (或「資料庫 DR」)。如要進一步瞭解這個概念，請參閱「Microsoft SQL Server 的災難復原」一文。在理想情況下，次要資料庫的狀態會與主要資料庫在主要資料庫無法使用時一致，或者次要資料庫只遺失主要資料庫中一小部分的最新交易事件資料。

災難復原架構

針對 Microsoft SQL Server，下圖顯示支援資料庫 DR 的最低架構。

圖 1. 使用 Microsoft SQL Server 的標準災難復原架構。

架構的運作方式如下：

• 兩個 Microsoft SQL Server 執行個體 (主要執行個體和待命執行個體) 位於相同地區 (R1) 但不同區域 (區域 A 和 B)。R1 中的兩個例項會使用同步提交模式協調狀態。使用同步模式的原因是，它可支援高可用性，並維持一致的資料狀態。
• 一個 Microsoft SQL Server 執行個體 (次要或災難復原執行個體) 位於第二個區域 (R2)。針對 DR，R2 中的次要執行個體會使用非同步提交模式，與 R1 中的主執行個體同步。非同步模式的效能較佳，因此會被使用 (不會減緩主要例項中的提交處理作業)。

上圖的架構顯示可用性群組。如果可用性群組與事件監聽器搭配使用，當用戶端由下列項目提供服務時，可用性群組會為用戶端提供相同的連線字串：

• 主要執行個體
• 待命執行個體 (區域故障後)
• 次要執行個體 (在區域發生故障後，以及次要執行個體成為新的主要執行個體後)

在上述架構的變化版本中，您將第一個區域 (R1) 中的兩個執行個體部署到同一個可用區。這種做法或許可改善效能，但可用性不高；您可能需要等待單一區域停機，才能啟動 DR 程序。

基本災難復原程序

當某個區域無法使用，且主要資料庫發生容錯移轉，以便在其他運作區域中恢復處理作業時，災難復原程序就會開始。DR 程序會規定必須採取的手動或自動操作步驟，以便減輕區域故障情形，並在可用的區域中建立執行中的主機例項。

基本資料庫 DR 程序包含下列步驟：

1. 執行主要資料庫執行個體的第一個區域 (R1) 無法使用。
2. 營運團隊會認定並正式確認災難，並決定是否需要容錯移轉。
3. 如果需要容錯移轉，第二個區域 (R2) 中的次要資料庫執行個體就會成為新的主要執行個體。
4. 用戶端會繼續處理新的主要資料庫，並存取 R2 中的主執行個體。

雖然這個基本程序會再次建立可運作的主要資料庫，但不會建立完整的 DR 架構，也就是新的主要資料庫有待命和次要資料庫執行個體。

完整的災難復原程序

完整的 DR 程序會在備援後，新增步驟來建立完整的 DR 架構，進而擴充基本 DR 程序。下圖為完整的資料庫 DR 架構。

圖 2：災難復原，主要區域 (R1) 無法使用。

完整的資料庫 DR 架構運作方式如下：

1. 執行主要資料庫執行個體的第一個區域 (R1) 無法使用。
2. 營運團隊會認定並正式確認災難，並決定是否需要容錯移轉。
3. 如果需要容錯移轉，則會將第二個區域 (R2) 中的次要資料庫執行個體設為主要執行個體。
4. 系統會建立並在 R2 中啟動另一個次要執行個體 (即新待命執行個體)，然後將其新增至主要執行個體。備援執行個體位於與主要執行個體不同的區域。主要資料庫現在包含兩個可確保高可用性的執行個體 (主要和待命)。
5. 在第三個區域 (R3) 中，系統會建立並啟動新的次要 (待命) 資料庫執行個體。這個次要執行個體會非同步連線至 R2 中的新主要執行個體。此時，系統會重新建立原始的災難復原架構並開始運作。

改用已復原的區域

第一個區域 (R1) 重新上線後，即可代管新的次要資料庫。如果 R1 很快就會開放，您可以在 R1 中實作完整復原程序中的步驟 5，而非 R3 (第三個區域)。在這種情況下，不需要第三個區域。

下圖顯示如果 R1 及時推出，架構會是什麼樣子。

圖 3：失敗的區域 R1 再次可用後的災難復原。

在這個架構中，復原步驟與前述「完整的災難復原程序」一節所述相同，但差別在於 R1 會成為次要執行個體的位置，而非 R3。

選擇 SQL Server 版本

本教學課程支援下列 Microsoft SQL Server 版本：

• SQL Server 2016 Enterprise 版
• SQL Server 2017 Enterprise 版
• SQL Server 2019 Enterprise 版
• SQL Server 2022 Enterprise 版本

本教學課程會使用 SQL Server 中的 AlwaysOn 可用性群組功能。

如果您不需要高可用性 (HA) Microsoft SQL Server 主要資料庫，且單一資料庫執行個體就足以做為主要資料庫，則可以使用下列 SQL Server 版本：

• SQL Server 2016 Standard 版
• SQL Server 2017 Standard 版
• SQL Server 2019 Standard 版
• SQL Server 2022 Standard 版

SQL Server 2016、2017、2019 和 2022 版本已在映像檔中安裝 Microsoft SQL Server Management Studio，因此您不需要另外安裝。不過，在實際執行環境中，我們建議您在各個區域的個別 VM 上安裝一個 Microsoft SQL Server Management Studio 執行個體。如果您設定高可用性環境，請為每個區域安裝 Microsoft SQL Server Management Studio 一次，以確保在其他區域無法使用時，仍可使用該工具。

設定 Microsoft SQL Server 以便跨區域進行 DR

本節會使用下列 Microsoft SQL Server 映像檔：

• sql-ent-2016-win-2016 (適用於 Microsoft SQL Server 2016 Enterprise 版)
• sql-ent-2017-win-2016 (適用於 Microsoft SQL Server 2017 Enterprise 版)
• sql-ent-2019-win-2019 (適用於 Microsoft SQL Server 2019 Enterprise 版)
• sql-ent-2022-win-2022 for Microsoft SQL Server 2022 Enterprise Edition

如需圖片的完整清單，請參閱「圖片」。

設定兩個執行個體的高可用性叢集

如要為 SQL Server 設定多區域資料庫 DR 架構，請先在某個區域中建立兩個執行個體的高可用性 (HA) 叢集。一個執行個體做為主要執行個體，另一個做為次要執行個體。如要完成這個步驟，請按照「設定 SQL Server AlwaysOn 可用性群組」中的操作說明進行。本教學課程將使用 us-central1 做為主要區域 (稱為 R1)。開始前，請先詳閱下列注意事項：

• 如果您按照「設定 SQL Server AlwaysOn 可用性群組」一文中的步驟操作，就會在同一個區域 (us-central1) 中建立兩個 SQL Server 執行個體。您會在 us-central1-a 中部署主要 SQL Server 執行個體 (node-1)，並在 us-central1-b 中部署待命執行個體 (node-2)。

• 雖然您為本教學課程實作圖 4 中的架構，但在多個區域中設定網域控制器是最佳做法。這種做法可確保您建立可支援 HA 和 DR 的資料庫架構。舉例來說，如果某個區域發生服務中斷，該區域不會成為已部署架構的單一故障點。

圖 4：本教學課程中實作的標準災難復原架構。

新增次要執行個體以便進行災難復原作業

接下來，您將設定第三個 SQL Server 執行個體 (名為 node-3 的次要執行個體)，並按照下列方式設定網路：

1. 為 Windows Server 容錯移轉叢集節點建立專屬指令碼。這個指令碼會安裝必要的 Windows 功能，並為 WSFC 和 SQL Server 建立防火牆規則。並且格式化資料磁碟，並為 SQL Server 建立資料和記錄資料夾：

   cat << "EOF" > specialize-node.ps1
   
   $ErrorActionPreference = "stop"
   
   # Install required Windows features
   Install-WindowsFeature Failover-Clustering -IncludeManagementTools
   Install-WindowsFeature RSAT-AD-PowerShell
   
   # Open firewall for WSFC
   netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997
   
   # Open firewall for SQL Server
   netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433
   
   # Open firewall for SQL Server replication
   netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
   
   # Format data disk
   Get-Disk |
    Where partitionstyle -eq 'RAW' |
    Initialize-Disk -PartitionStyle MBR -PassThru |
    New-Partition -AssignDriveLetter -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false
   
   # Create data and log folders for SQL Server
   md d:\Data
   md d:\Logs
   EOF
   

2. 初始化下列變數：

   VPC_NAME=VPC_NAME
   SUBNET_NAME=SUBNET_NAME
   REGION=us-east1
   PD_SIZE=200
   MACHINE_TYPE=n2-standard-8
   

   其中：

   • VPC_NAME：虛擬私有雲名稱
   • SUBNET_NAME：us-east1 區域的子網路名稱

3. 建立 SQL Server 執行個體：

   gcloud compute instances create node-3 \
   --zone $REGION-b \
   --machine-type $MACHINE_TYPE \
   --subnet $SUBNET_NAME \
   --image-family sql-ent-2022-win-2022 \
   --image-project windows-sql-cloud \
   --tags wsfc,wsfc-node \
   --boot-disk-size 50 \
   --boot-disk-type pd-ssd \
   --boot-disk-device-name "node-3" \
   --create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
   --metadata enable-wsfc=true \
   --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1
   

4. 為新的 SQL Server 執行個體設定 Windows 密碼：

   1. 在 Google Cloud 控制台中，前往 Compute Engine 頁面。

      前往 Compute Engine

   2. 在 Compute Engine 叢集 node-3 的「Connect」欄中，選取「Set windows password」下拉式清單。

   3. 設定使用者名稱和密碼。並記下來，以便稍後使用。

5. 按一下「RDP」，即可連線至 node-3 執行個體。

6. 輸入上一個步驟中的使用者名稱和密碼，然後按一下「OK」。

7. 將執行個體新增至 Windows 網域：

   1. 在「開始」按鈕上按一下滑鼠右鍵 (或按下 Win + X 鍵)，然後按一下「Windows PowerShell (系統管理員)」。

   2. 按一下「是」確認權限提升提示。

   3. 將電腦加入 Active Directory 網域並重新啟動：

      Add-Computer -Domain DOMAIN -Restart
      

      將 DOMAIN 替換為 Active Directory 網域的 DNS 名稱。

      請等待約 1 分鐘，讓重新啟動程序完成。

將次要執行個體新增至容錯移轉叢集

接下來，您將次要執行個體 (node-3) 新增至 Windows 容錯集群：

1. 使用 RDP 連線至 node-1 或 node-2 執行個體，並以管理員使用者身分登入。

2. 以系統管理員身分開啟 PowerShell 視窗，並為本教學課程中的叢集環境設定變數：

   $node3 = "node-3"
   $nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
   

   將 SQLSRV_CLUSTER 替換為 SQL Server 叢集的名稱。

3. 將次要執行個體新增至叢集：

   Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
   

   這個指令可能需要一段時間才能執行。由於程序可能會停止回應，且不會自動返回，因此請不時按下 Enter。

4. 在節點中啟用 AlwaysOn 高可用性功能：

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

節點現在是容錯移轉叢集的一部分。

將次要執行個體新增至現有可用性群組

接下來，請將 SQL Server 執行個體 (次要執行個體) 和資料庫新增至可用性群組：

1. 使用遠端桌面連線至 node-3。使用您的網域使用者帳戶登入。

2. 開啟 SQL Server 組態管理工具。

3. 在導覽窗格中，選取「SQL Server 服務」

4. 在服務清單中，在「SQL Server (MSSQLSERVER)」上按一下滑鼠右鍵，然後選取「Properties」。

5. 在「以以下身分登入」下方變更帳戶：

   • 帳戶名稱：DOMAIN\sql_server 其中 DOMAIN 是 Active Directory 網域的 NetBIOS 名稱。
   • 密碼：輸入先前為 sql_server 網域帳戶選擇的密碼。

6. 按一下 [確定]。

7. 系統提示重新啟動 SQL Server 時，請選取「是」。

8. 在任何一個執行個體節點 node-1、node-2 或 node-3 中，開啟 Microsoft SQL Server Management Studio，然後連線至主要執行個體 node-1。

   1. 前往「Object Explorer」(物件探索工具)。
   2. 選取「Connect」下拉式清單。
   3. 選取「資料庫引擎」。
   4. 在「Server Name」下拉式清單中，選取「node-1」。如果清單中沒有叢集，請在欄位中輸入叢集名稱。

9. 按一下「新查詢」。

10. 請貼上以下指令，將 IP 位址新增至用於節點的事件監聽器，然後按一下「執行」：

    ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
    

    將 LOAD_BALANCER_IP_ADDRESS 替換為 us-east1 區域中負載平衡器的 IP 位址。

11. 在「物件總管」中，展開「AlwaysOn 高可用性」節點，然後展開「可用性群組」節點。

12. 在名稱為 bookshelf-ag 的可用性群組上按一下滑鼠右鍵，然後選取「Add Replica」。

13. 在「簡介」頁面上，依序點選「AlwaysOn 高可用性」節點和「可用性群組」節點。

14. 在「連線至複本」頁面中，按一下「連線」，連線至現有的次要複本 node-2。

15. 在「Specify Replicas」頁面中，按一下「Add Replica」，然後新增新節點 node-3。請勿選取「自動備援」，因為自動備援會導致同步提交。這種設定會跨越區域邊界，因此不建議採用。

16. 在「Select Data Synchronization」(選取資料同步處理) 頁面上，選取「Automatic seeding」(自動播種)。

    由於沒有接聽程式，Validation 頁面會產生警告，您可以忽略這項警告。

17. 完成精靈步驟。

node-1 和 node-2 的容錯移轉模式為自動，而 node-3 則為手動。這項差異是區分高可用性和災難復原的一種方式。

可用性群組現在已準備就緒。您已設定兩個節點以提供高可用性，並設定第三個節點用於災難復原。

模擬災難復原

在本節中，您將測試本教學課程的災難復原架構，並考慮採用選用的 DR 實作方式。

模擬服務中斷情況並執行 DR 容錯功能

1. 模擬主要區域的故障或中斷情形：

   1. 在 node-1 的 Microsoft SQL Server Management Studio 中，連線至 node-1。

   2. 建立表格。在後續步驟中新增複本後，請檢查這個資料表是否存在，以驗證複本是否正常運作。

      USE bookshelf
      GO
      CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
      GO
      

   3. 在 Cloud Shell 中，關閉主要區域 us-central1 中的兩部伺服器：

      gcloud compute instances stop node-2 --zone us-central1-b --quiet
      gcloud compute instances stop node-1 --zone us-central1-a --quiet
      

2. 在 node-3 的 Microsoft SQL Server Management Studio 中，連線至 node-3。

3. 執行容錯移轉，並將可用性模式設為同步提交。由於節點處於非同步提交模式，因此必須強制執行備援。

   ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [bookshelf-ag]
   MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   您可以繼續處理，node-3 現為主要執行個體。

4. (選用) 在 node-3 中建立新資料表。將備用資源與新主要執行個體同步後，請檢查這個資料表是否已複製到備用資源。

   USE bookshelf
   GO
   CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
   GO
   

雖然 node-3 目前是主要執行個體，但您可能會想改回原始區域，或設定新的次要執行個體和待命執行個體，以便再次建立完整的 DR 架構。下一節將討論這些選項。

(選用) 重新建立可完全複製交易的 DR 架構

這個用途可解決以下失敗情況：所有交易都會在主要資料庫發生故障前，從主要資料庫複製到次要資料庫。在這個理想情況下，資料不會遺失；次要資料庫的狀態會與發生故障時的主要資料庫一致。

在這種情況下，您可以透過兩種方式重建完整的 DR 架構：

• 改用原始的預設主機和備用機器 (如果有)。
• 為 node-3 建立新的待命和次要資料庫，以防原始主要和待命資料庫無法使用。

方法 1：改回原始的預設主機和備用機

1. 在 Cloud Shell 中，啟動原始 (舊) 主機和備援主機：

   gcloud compute instances start node-1 --zone us-central1-a --quiet
   gcloud compute instances start node-2 --zone us-central1-b --quiet
   

2. 在 Microsoft SQL Server Management Studio 中，將 node-1 和 node-2 新增為次要複本：

   1. 在 node-3 上，以非同步提交模式新增兩個伺服器：

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. 在 node-1 上，重新開始同步處理資料庫：

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

   3. 在 node-2 上，重新開始同步處理資料庫：

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

3. 再次將 node-1 設為主要版本：

   1. 在 node-3 上，將 node-1 的可用性模式變更為同步提交。執行個體 node-1 又會再次成為主要執行個體。

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. 在 node-1 上，將 node-1 設為主要節點，並將其他兩個節點設為次要節點：

      USE [master]
      GO
      -- Node 1 becomes primary
      ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
      GO
      
      -- Node 2 has synchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      
      -- Node 3 has asynchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

所有指令都成功執行後，node-1 會成為主要節點，其他節點則為次要節點，如下圖所示。

方法 2：設定新的主機和待機機器

您可能無法從失敗中復原原始的主要和備用執行個體，或者復原這些執行個體所需的時間過長，或是無法存取該地區。一種做法是將 node-3 保留為主要執行個體，然後建立新的待命和次要執行個體，如下圖所示。

圖 5. 災難復原，原始主要區域 R1 無法使用。

這個實作方式需要您執行下列操作：

• 將 node-3 保留為 us-east1 的主要項目。

• 在 us-east1 的不同區域中新增新的待命執行個體 (node-4)。這個步驟會將新部署作業設為高可用性。

• 在其他區域 (例如 us-west2) 中建立新的次要執行個體 (node-5)。這個步驟會設定新的災難復原部署作業。整體部署作業現已完成。資料庫架構完全支援 HA 和 DR。

(選用) 在缺少交易時執行備用方法

不理想的失敗情況是指，在失敗點時，一或多個在主機上提交的交易未複製到次要機 (也稱為硬故障)。在備援期間，所有未複寫的已提交交易都會遺失。

如要測試此情況的容錯移轉步驟，您必須產生嚴重故障。產生嚴重錯誤的最佳做法如下：

• 變更網路，讓主要和次要執行個體之間無法連線。
• 以某種方式變更主鍵，例如新增資料表或插入資料。
• 依照先前所述的步驟完成容錯移轉程序，讓次要資料庫成為新的主資料庫。

備援程序的步驟與理想情況相同，唯一的差異是，在網路連線中斷後，新增至主要執行個體的表格不會顯示在次要執行個體中。

要處理硬式故障，唯一的做法就是從可用性群組中移除副本 (node-1 和 node-2)，然後再次同步副本。同步處理會將狀態變更為與次要狀態一致。在失敗發生前未複製的交易都會遺失。

如要將 node-1 新增為次要執行個體，您可以按照先前新增 node-3 的步驟操作 (請參閱先前的將次要執行個體新增至備援叢集)，但有以下差異：node-3 現為主要執行個體，而非 node-1。您必須將任何 node-3 例項替換為您新增至可用性群組的伺服器名稱。如果您要重複使用相同的 VM (node-1 和 node-2)，則不必將伺服器新增至 Windows Server 容錯移轉叢集，只需將 SQL Server 例項新增回可用性群組即可。

此時，node-3 是主要活動，node-1 和 node-2 則是次要活動。您現在可以改用 node-1，將 node-2 設為待機，並將 node-3 設為次要。系統現在的狀態與發生失敗前相同。

自動容錯移轉

自動將主要執行個體容錯移轉至次要執行個體可能會造成問題。當原始主要執行個體再次可用時，如果部分用戶端存取次要執行個體，而其他用戶端則寫入已還原的主要執行個體，就可能發生分割腦的情況。在這種情況下，主資料來源和次要資料來源可能會並行更新，且狀態會有所差異。為避免這種情況發生，本教學課程提供手動容錯移轉的操作說明，讓您決定是否要進行容錯移轉 (或何時進行)。

如果您實作自動容錯移轉，請務必確保只有一個已設定的執行個體是主要執行個體，且可進行修改。任何待機或次要執行個體都不得向任何用戶端提供寫入權限 (狀態複製的 primary 除外)。此外，您必須避免在短時間內發生連串的後續備援。舉例來說，每五分鐘一次的容錯移轉並非可靠的災難復原策略。對於自動容錯程序，您可以建立防護措施，以防範上述問題情境，甚至在必要時，讓資料庫管理員做出複雜的決定。

其他部署架構

本教學課程會設定災難復原架構，其中次要執行個體會在容錯時成為主要執行個體，如下圖所示。

圖 6：使用 Microsoft SQL Server 的標準災難復原架構。

也就是說，在發生容錯時，所產生的部署作業會有一個執行個體，直到可進行備援，或您設定待機 (高可用性) 和次要 (DR) 為止。

另一種部署架構是設定兩個次要執行個體。兩個執行個體都是主要執行個體的備用資源。如果發生容錯移轉，您可以將其中一個次要備用資源重新設定為待命備援。下圖顯示備援機制前後的部署架構。

圖 7. 含有兩個次要執行個體的標準災難復原架構。

圖 8. 標準災難復原架構，在備援後有兩個次要執行個體。

雖然您仍必須將兩個次要資料庫之一設為待命資料庫 (圖 8)，但這個程序比從頭開始建立及設定新的待命資料庫快上許多。

您也可以使用類似於使用兩個次要執行個體的架構，設定備援機制。除了在第二個區域中設有兩個次要資料中心 (圖 7)，您也可以在第三個區域中部署另外兩個次要資料中心。這項設定可讓您在主要區域發生故障後，有效建立支援 HA 和 DR 的部署架構。