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

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

  • 副本容錯移轉：如果區域故障，可立即將主要執行個體容錯移轉至災難復原副本。如果是 SQL Server 適用的 Cloud SQL，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 與進階災難復原功能的注意事項，請參閱「搭配使用 PITR 與進階災難復原功能」。

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

將舊的主要執行個體重新設定為唯讀副本後，DNS 寫入端點 (先前解析為舊的主要執行個體) 會解析為新的主要執行個體。

如果您在災難復原 (DR) 副本上設定 Private Service Connect 傳出連線，則在切換作業後，當 DR 副本升級為主要執行個體時，傳出連線會繼續在建立的新主要執行個體上運作。如果未在災難復原 (DR) 副本設定傳出連線，則必須在新的主要執行個體啟用 Private Service Connect 傳出連線，服務才能在切換作業後繼續運作。

事前準備

執行切換作業前，請先完成下列事項：

  • 如果您尚未建立 DR 副本，請先完成這項作業。
  • 使用 sp_help_revlogin 預存程序，轉移在建立災難復原副本後，於主要執行個體上建立的任何 SQL Server 登入資訊。同步處理登入資訊可確保應用程式在切換作業完成後立即重新連線。
  • 確認主要執行個體和災難復原副本皆已上線。
  • 如果您使用 DNS 寫入端點，請確認主要執行個體和 DR 副本的 SSL 設定相同。舉例來說，如果 DR 副本設為強制執行 SSL 加密，但主要執行個體允許未加密的連線，則切換作業完成後，用戶端將無法連線至新的主要執行個體。
  • 隨選備份主要執行個體。這項備份措施是為了防範未然，以便在發生任何非預期故障時復原。

執行切換作業

gcloud

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

gcloud sql instances switchover REPLICA_NAME

請替換下列變數：

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

Terraform

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

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 副本會立即接替主要執行個體的角色，因此可能因為複製延遲，而未包含舊主要執行個體的所有資料。因此，副本容錯移轉可能會導致資料遺失。

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

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

如要進一步瞭解將 PITR 與進階災難復原搭配使用的注意事項，請參閱「將 PITR 與進階災難復原搭配使用」。

叫用副本容錯移轉作業後，DNS 寫入端點會解析為新的主要執行個體，而非舊的主要執行個體。

如果您在災難復原 (DR) 副本上設定 Private Service Connect 傳出連線，則在副本容錯移轉作業後，當 DR 副本升級為主要執行個體時，傳出連線會繼續在建立的新主要執行個體上運作。如果未在災難復原 (DR) 副本設定傳出連線，則必須在新的主要執行個體啟用 Private Service Connect 傳出連線，服務才能在副本容錯移轉作業後繼續運作。

事前準備

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

  • 如果您尚未建立 DR 副本，請建立 DR 副本。
  • 如果主要執行個體仍可存取，請使用 sp_help_revlogin 預存程序，將任何未同步的 SQL Server 登入資訊轉移至災難復原副本。定期同步處理登入資訊，可確保應用程式在容錯移轉後立即重新連線。
  • 確認 DR 副本已上線且健康狀態良好。

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

gcloud

如要叫用副本容錯移轉至災難備援副本，請使用下列指令：

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. 查看第一階段的狀態。

    控制台

    如要確認災難備援副本是否已升級為獨立執行個體，請按照下列步驟操作：

    1. 前往 Google Cloud 控制台的「Cloud SQL Instances」(Cloud SQL 執行個體) 頁面。

      前往「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 訊息。

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

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

搭配使用 PITR 和進階災難復原

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

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

詳情請參閱「使用 PITR」。

在新的主要執行個體上啟用 PITR 後，您就能將執行個體還原至其為有效主要執行個體的任何時間點。

備用資源容錯移轉期間發生腦裂

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

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

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

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

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

VPC Service Controls 和進階災難復原建議

如果您使用 VPC Service Controls，請確認 service perimeter 允許所有復原作業 (例如時間點復原 (PITR) 作業) 的必要通訊，尤其是當您使用 CMEK 且金鑰位於其他專案時。

切換和副本容錯移轉等進階災難復原作業，可啟用或重新設定 PITR 等功能。如果未正確設定 CMEK 和跨專案金鑰存取權的 service perimeter，VPC Service Controls 可能會封鎖這些功能。

  • 將 KMS 金鑰專案與執行個體放在同一個 perimeter：最佳做法是將包含 KMS 金鑰的專案，與 Cloud SQL 執行個體放在同一個 VPC Service Controls perimeter。
  • 使用 perimeter bridge：另一個較不建議的做法是使用 perimeter bridge 連結不同 perimeter 中的專案。
  • 測試：使用 VPC Service Controls 模擬測試模式，測試災難復原程序 (例如切換)，並找出潛在的 VPC Service Controls 違規事項，而不強制執行。

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

限制

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

  • 您無法將外部副本指定為災難復原副本。

  • Terraform 不支援副本容錯移轉作業。

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

疑難排解

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

後續步驟