使用進階災難復原 (DR) 功能

本頁說明如何使用進階災害復原 (DR)。進階 DR 提供兩項主要功能：

  • 備用資源容錯移轉功能可讓您在區域發生故障時，立即將主要執行個體容錯移轉至災難復原備用資源。如果是 SQL Server 適用的 Cloud SQL，DR 副本是可串聯的副本。
  • 切換可讓您反轉主要執行個體和 DR 備用資源的角色，不會遺失任何資料。您可以使用切換功能，在副本容錯移轉後將部署作業還原至原始部署狀態，也可以使用切換功能測試 DR。

進階 DR 僅支援 Cloud SQL Enterprise Plus 版本執行個體。

事前準備

如果您打算使用 Google Cloud SDK，則必須使用 502.0.0 以上版本。如要查看 Google Cloud SDK 版本，請執行 gcloud --version。如要更新 Google Cloud SDK，請執行 gcloud components update。

如要安裝 Google Cloud SDK，請參閱「安裝 gcloud CLI」。

建立 DR 備用資源

使用進階災難復原功能前，請在與主要執行個體不同的地區，建立主要執行個體的可串聯副本。

執行切換作業

建立 DR 副本後，即可執行切換作業。不過，為求最佳做法，請避免在下列情況下執行切換作業：

  • 主要執行個體正在使用中。
  • 正在執行管理員作業，例如自動備份，或是啟用/停用高可用性 (HA)。

為避免逾時，建議在交易量較低時執行切換。

切換完成後，作業會在新主要執行個體升級後，立即備份新主要執行個體 (先前的 DR 副本)。備份作業可能需要 5 到 15 分鐘，視磁碟大小而定。備份完成後，如要在升級的執行個體上使用 PITR，請手動啟用 PITR。 如要進一步瞭解搭配使用 PITR 與進階 DR 時的注意事項，請參閱「搭配使用 PITR 與進階 DR」。

切換作業完成後，您會發現複製方向已反轉。

舊的主要執行個體重新設定為唯讀備用資源後，先前解析為舊主要執行個體的 DNS 寫入端點，會解析為新的主要執行個體。

事前準備

執行切換作業前，請先完成下列步驟：

  • 如果尚未建立，請建立 DR 副本。
  • 確認主要執行個體和 DR 副本已上線。
  • 如果您使用 DNS 寫入端點，請確認主要執行個體和 DR 副本的 SSL 設定相同。舉例來說，如果 DR 副本設定為強制執行 SSL 加密，但主要執行個體允許未加密的連線，那麼在完成切換作業後，用戶端就無法連線至新的主要執行個體。
  • 對主要執行個體執行隨選備份。以防需要從任何意外故障中復原。

執行切換作業

gcloud

如要執行切換作業，請執行下列指令：

gcloud sql instances switchover REPLICA_NAME

請替換下列變數：

  • REPLICA_NAME：您希望主要執行個體與其互換角色的 DR 副本名稱。

Terraform

如要開始切換作業，請使用 Terraform 資源。 如要將 DR 副本設為新的主要執行個體，請使用第一個範例。範例包含 Terraform 設定變更的註解，您需要進行這些變更，才能切換主要執行個體和 DR 副本。

resource "google_sql_database_instance" "original-primary" {
  name             = "sqlserver-primary-instance-name"
  region           = "us-east1"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  instance_type    = "CLOUD_SQL_INSTANCE"
  root_password    = "INSERT-PASSWORD-HERE"
  replica_names    = ["sqlserver-replica-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name = "sqlserver-replica-instance-name"
  # Remove or comment out the master_instance_name
  # master_instance_name = google_sql_database_instance.original-primary.name
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  # Remove or comment out the replica_configuration section
  # replica_configuration {
  #  cascadable_replica = true
  # }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

完成變更後，請執行 terraform plan，更新主要和 DR 副本。確認輸出內容包含 Plan: 0 to add, 1 to change, 0 to destroy.。如要執行切換作業，請執行 terraform apply。

此時，原先的主要執行個體是新主要執行個體的副本。不過，這項變更不會自動反映在 Terraform 狀態中。 如要將原始主要執行個體設為 Terraform 狀態中新主要執行個體的副本，請使用第二個範例。第二個範例提供註解，說明您在執行第一個範例後需要進行的變更。

resource "google_sql_database_instance" "original-primary" {
  name = "sqlserver-primary-instance-name"
  # Set master_instance_name to the new primary instance, the original DR replica.
  master_instance_name = "sqlserver-replica-instance-name"
  region               = "us-east1"
  database_version     = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Remove  values from the replica_names field, but don't remove the field itself.
  replica_names = []
  # Add replica_configuration section and set cascadable_replica to true.
  replica_configuration {
    cascadable_replica = true
  }
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name             = "sqlserver-replica-instance-name"
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

如果 Terraform 狀態更新成功，對第二個範例執行 terraform plan 時，會顯示類似下列內容的訊息：

No changes. Your infrastructure matches the configuration.

如果您執行 terraform apply，會收到類似下列內容的訊息：

Resources: 0 added, 0 changed, 0 destroyed.

REST v1

使用任何要求資料之前，請先替換以下項目：

  • PROJECT_ID：主要執行個體和 DR 副本的 Google Cloud 專案 ID 或專案編號。
  • REPLICA_NAME：DR 副本的名稱。

HTTP 方法和網址：

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

如要傳送要求，請展開以下其中一個選項：

您應該會收到如下的 JSON 回應：

REST v1beta4

使用任何要求資料之前，請先替換以下項目：

  • PROJECT_ID：主要執行個體和 DR 副本的 Google Cloud 專案 ID 或專案編號。
  • REPLICA_NAME：DR 副本的名稱。

HTTP 方法和網址：

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

如要傳送要求，請展開以下其中一個選項：

您應該會收到如下的 JSON 回應：

叫用備用資源容錯移轉，執行 DR

如果發生區域故障或災難，您可以對指定的 DR 副本叫用副本容錯移轉作業，執行 DR。如要執行備用資源容錯移轉，請升級 DR 備用資源。與切換不同，DR 副本的升級是立即進行。

由於 DR 副本會立即接手主要執行個體的工作，因此副本可能因複製延遲而未包含舊主要執行個體的所有資料。因此，備用資源容錯移轉可能會導致資料遺失。

在升級過程中，備用資源容錯移轉會在 DR 備用資源成為新的主要執行個體後，立即備份新的主要執行個體 (先前的 DR 備用資源)。備份完成後，新的主要執行個體就會完全啟用時間點復原 (PITR) 功能。視新 (和舊) 主要執行個體的磁碟大小而定，完成這項備份作業可能需要 5 到 15 分鐘。備份期間無法使用 PITR。

舊的主要執行個體恢復連線後，副本容錯移轉程序會進行備份。備份完成後，系統會將舊的主要執行個體重新建立為新主要執行個體的唯讀備用資源。

如要進一步瞭解如何搭配使用 PITR 與進階 DR，請參閱「搭配使用 PITR 與進階 DR」。

啟動副本容錯移轉作業後，先前解析為舊主要執行個體的 DNS 寫入端點，會解析為新的主要執行個體。

事前準備

執行副本容錯移轉前，請先完成下列步驟：

  • 如果尚未建立，請建立 DR 副本。
  • 確認 DR 副本已連線且健康狀態良好。

執行備用資源容錯移轉作業

gcloud

如要叫用副本容錯移轉至 DR 副本，請使用下列指令：

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

請替換下列變數：

  • REPLICA_NAME：DR 備用資源的名稱

REST v1

使用任何要求資料之前，請先替換以下項目：

  • PROJECT_ID：主要執行個體和 DR 副本的 Google Cloud 專案 ID 或專案編號。
  • REPLICA_NAME：DR 副本的名稱。
  • ENABLE_REPLICA_FAILOVER：設為 true，即可使用副本容錯移轉。如果設為 false，API 會使用一般 promoteReplica 方法，不會進行副本容錯移轉。

HTTP 方法和網址：

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

如要傳送要求，請展開以下其中一個選項：

您應該會收到如下的 JSON 回應：

REST v1beta4

使用任何要求資料之前，請先替換以下項目：

  • PROJECT_ID：主要執行個體和 DR 副本的 Google Cloud 專案 ID 或專案編號。
  • REPLICA_NAME：DR 副本的名稱。
  • ENABLE_REPLICA_FAILOVER：設為 true，即可使用副本容錯移轉。如果設為 false，API 會使用一般 promoteReplica 方法，不會進行副本容錯移轉。

HTTP 方法和網址：

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

如要傳送要求，請展開以下其中一個選項：

您應該會收到如下的 JSON 回應：

檢查備用資源容錯移轉的狀態

備用資源容錯移轉作業分為兩個階段。第一階段是升級 DR 副本。 第二階段是將舊的主要執行個體重新建立為唯讀備用資源。

如要檢查備用資源容錯移轉的狀態，請檢查每個階段的狀態。

  1. 檢查第一階段的狀態。

    控制台

    如要確認 DR 副本是否已升級為獨立執行個體，請執行下列操作：

    1. 前往 Google Cloud 控制台的「Cloud SQL Instances」頁面。

      前往 Cloud SQL 執行個體

    2. 找出您升級的 DR 副本名稱。
    3. 確認新主要執行個體的「Type」(類型) 欄中顯示 SQL Server VERSION。

    gcloud

    您可以執行下列指令來檢查狀態：

    gcloud sql instances describe DR_REPLICA_NAME

    請替換下列變數：

    • DR_REPLICA_NAME：升級的 DR 副本名稱

    在輸出內容中，確認顯示下列欄位，且副本已成為獨立的 Cloud SQL 主要執行個體：

    instanceType: CLOUD_SQL_INSTANCE

  2. 如要確認第二階段是否完成，請檢查執行個體上的作業記錄，確認是否出現 RECONFIGURE_OLD_PRIMARY 訊息。

    這則訊息的顯示時間取決於舊的主要執行個體何時恢復連線，如果發生災害，可能需要幾分鐘或幾天。

    如要進一步瞭解如何檢查執行個體的作業記錄，請參閱「查看執行個體記錄」。

搭配進階 DR 使用 PITR

無論是切換或備用資源容錯移轉，如果 DR 備用資源升級為主要執行個體，且您想在升級後的執行個體上使用 PITR，就必須手動啟用 PITR。

啟用 PITR 後，系統會套用備份設定和交易記錄保留政策。如未指定這些設定的值，系統會套用 14 天的預設值。

詳情請參閱「使用 PITR」一文。

在新主要執行個體上啟用 PITR 後，您就可以將執行個體還原至任何時間點，前提是該執行個體在當時是主要執行個體。

備用資源容錯移轉期間發生核心分裂

如果主要執行個體在透過備用資源容錯移轉升級備用資源時，持續接受寫入作業，就可能發生腦裂。備用資源升級後，當舊的主要執行個體再次可用時，系統會將其重建為升級執行個體的備用資源，並進行最終備份。這個備份可用於復原未寫入升級副本的任何腦裂資料。

刪除副本上的備份和交易記錄

如果啟用 PITR 和備份的主要執行個體變成唯讀副本，系統會保留並套用該執行個體做為主要執行個體時的最後一次備份和 PITR 保留政策。即使新的主要執行個體不會進行備份，系統仍會根據上次設定的政策，刪除唯讀備用資源上的舊備份和交易記錄，這些資料可用於 PITR。

舉例來說，如果執行個體設定為每天自動備份，並保留 7 個備份檔和 7 天的 PITR 記錄，則當這個執行個體成為唯讀副本時，系統每天會刪除超過 7 天的資料。

如需盡快刪除備份，可以手動移除備份。詳情請參閱「刪除備份」。

VPC Service Controls 和進階 DR 的建議

如果您使用 VPC Service Controls，請確保服務範圍允許所有復原作業 (例如時間點復原 (PITR) 作業) 的必要通訊，特別是您在不同專案中使用 CMEK 金鑰時。

進階 DR 作業 (例如切換和副本容錯移轉) 可以啟用或重新設定 PITR 等功能，但如果服務範圍未正確設定 CMEK 和跨專案金鑰存取權，VPC Service Controls 就會封鎖這些功能。

  • 將 KMS 金鑰專案保留在與執行個體相同的安全防護範圍內：最佳做法是將包含 KMS 金鑰的專案，納入與 Cloud SQL 執行個體相同的 VPC Service Controls 安全防護範圍。
  • 使用重疊範圍：做為次要 (較不建議) 選項，您可以使用重疊範圍連結不同範圍中的專案。
  • 測試：使用 VPC Service Controls 模擬測試模式測試 DR 程序 (例如切換)，並找出潛在的 VPC Service Controls 違規事項，但不強制執行。

詳情請參閱「設定 VPC Service Controls」。

限制

  • 如果主要執行個體將時間點復原 (PITR) 的交易記錄儲存在磁碟上，您就無法將 Cloud SQL Enterprise Plus 版本的唯讀備用資源執行個體指定為災難復原備用資源。如要查看執行時間點復原 (PITR) 時，執行個體將記錄儲存在何處，請參閱「檢查用於 PITR 的交易記錄儲存位置」。

  • 您無法將外部副本指派為 DR 副本。

  • Terraform 不支援備用資源容錯移轉作業。

  • 您無法使用 Google Cloud 控制台執行副本容錯移轉或切換作業。

疑難排解

問題 疑難排解
切換作業失敗。
    確認執行個體符合所有規定的 DR 副本(可串聯副本) 需求。
  • 檢查資料庫中的交易量。如果交易量很高，作業可能會逾時。交易負載較低時，請考慮重試作業。
切換作業失敗，主要執行個體仍卡在唯讀模式中。 重新啟動資料庫，將主要執行個體恢復為寫入模式。
切換作業已完成，但 Google Cloud 控制台未顯示執行個體的新反向角色。 重新整理瀏覽器，即可顯示更新後的拓撲。
備用資源容錯移轉作業失敗。
  • 請確認您已為主要執行個體建立 DR 副本，且 DR 副本已上線。
  • 如果容錯移轉至 DR 備用資源失敗，請改為升級至一般 (非 DR) 唯讀備用資源。

後續步驟