高度な障害復旧（DR）を使用する

このページでは、高度な障害復旧（DR）を使用する方法について説明します。高度な DR には、2 つの主な機能があります。

  • レプリカ フェイルオーバーでは、リージョン障害が発生した場合、すぐにプライマリ インスタンスを DR レプリカにフェイルオーバーできます。Cloud SQL for SQL Server の場合、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 を使用する前に、プライマリ インスタンスとは異なるリージョンにプライマリ インスタンスのカスケード可能なレプリカを作成します。

切り替えを行う

DR レプリカを作成したら、切り替えオペレーションを実行できます。ただし、ベスト プラクティスとして、次の状況では切り替えオペレーションを行わないことをおすすめします。

  • プライマリ インスタンスがアクティブに使用されている。
  • 自動バックアップや高可用性（HA）の有効化 / 無効化などの管理オペレーションが進行中である。

タイムアウトを回避するには、トランザクションの量が少ないときに切り替えを行うことを検討してください。

切り替えが完了した後、新しいプライマリ インスタンスが昇格するとすぐに、オペレーションによって新しいプライマリ インスタンス（以前の DR レプリカ）のバックアップが作成されます。このバックアップは、ディスクサイズによって完了までに 5～15 分かかることがあります。このバックアップが完了したら、昇格したインスタンスで PITR を使用する場合は、手動で PITR を有効にする必要があります。高度な DR で PITR を使用する際の考慮事項については、高度な DR で PITR を使用するをご覧ください。

切り替えオペレーションが完了すると、レプリケーションの方向が逆になります。

古いプライマリ インスタンスがリードレプリカとして再構成されると、以前は古いプライマリ インスタンスに解決されていた DNS 書き込みエンドポイントが新しいプライマリ インスタンスに解決されます。

始める前に

切り替えオペレーションを実行する前に、次の操作を行います。

  • まだ作成していない場合は、DR レプリカを作成する。
  • プライマリ インスタンスと DR レプリカがオンラインであることを確認する。
  • DNS 書き込みエンドポイントを使用している場合は、プライマリ インスタンスと DR レプリカの SSL 構成が同じであることを確認します。たとえば、DR レプリカが SSL 暗号化を適用するように構成されていても、プライマリ インスタンスが暗号化されていない接続を許可している場合、切り替えオペレーションの完了後にクライアントは新しいプライマリ インスタンスに接続できなくなります。
  • プライマリ インスタンスのオンデマンド バックアップを取得する。このバックアップは、予期しない障害から復旧する必要がある場合に備えて行います。

切り替えオペレーションを実行する

gcloud

切り替えオペレーションを実行するには、次のコマンドを実行します。

gcloud sql instances switchover REPLICA_NAME

次の変数を置き換えます。

  • REPLICA_NAME: プライマリ インスタンスとロールを切り替える DR レプリカの名前。

Terraform

切り替えオペレーションを開始するには、Terraform リソースを使用します。DR レプリカを新しいプライマリ インスタンスにするには、最初のサンプルを使用します。このサンプルには、プライマリ インスタンスと 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 状態の新しいプライマリ インスタンスのレプリカにするには、2 番目のサンプルを使用します。2 つ目のサンプルには、最初のサンプルを実行した後に必要な変更を説明するコメントが記載されています。

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 状態が正常に更新された場合、2 番目のサンプルに対して 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 メソッドと URL:

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 メソッドと URL:

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 は利用できません。

古いプライマリ インスタンスがオンラインに戻ると、レプリカのフェイルオーバー プロセスがバックアップを取得します。このバックアップが取得された後、古いプライマリ インスタンスは新しいプライマリ インスタンスのリードレプリカとして再作成されます。

高度な DR で PITR を使用する際の考慮事項については、高度な DR で PITR を使用するをご覧ください。

レプリカのフェイルオーバー オペレーションを呼び出すと、以前は古いプライマリ インスタンスに解決されていた 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 メソッドと URL:

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 メソッドと URL:

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

リクエストを送信するには、次のいずれかのオプションを展開します。

次のような JSON レスポンスが返されます。

レプリカのフェイルオーバーのステータスを確認する

レプリカのフェイルオーバーには 2 つのフェーズがあります。フェーズ 1 では、DR レプリカを昇格します。フェーズ 2 では、古いプライマリ インスタンスをリードレプリカとして再作成します。

レプリカのフェイルオーバーのステータスを確認するには、各フェーズのステータスを確認します。

  1. 最初のフェーズのステータスを確認します。

    コンソール

    DR レプリカがスタンドアロン インスタンスに昇格されているかどうかを確認するには、次の操作を行います。

    1. Google Cloud コンソールで、Cloud SQL の [インスタンス] ページに移動します。

      Cloud SQL の [インスタンス] に移動

    2. 昇格した DR レプリカの名前を確認します。
    3. 新しいプライマリ インスタンスの [種類] 列に SQL Server VERSION が表示されていることを確認します。

    gcloud

    ステータスを確認するには、次のコマンドを実行します。

    gcloud sql instances describe DR_REPLICA_NAME

    次の変数を置き換えます。

    • DR_REPLICA_NAME: 昇格された DR レプリカの名前

    出力に次のフィールドが表示されていて、レプリカがスタンドアロンの Cloud SQL プライマリ インスタンスになったことを確認します。

    instanceType: CLOUD_SQL_INSTANCE

  2. フェーズ 2 が完了したことを確認するには、インスタンスのオペレーション ログでメッセージ RECONFIGURE_OLD_PRIMARY を確認します。

    このメッセージが表示されるのは、古いプライマリ インスタンスがオンラインに戻ったときです。災害が発生した場合、数分または数日かかることがあります。

    インスタンスのオペレーション ログを確認する方法については、インスタンスのログを表示するをご覧ください。

高度な DR で PITR を使用する

切り替えまたはレプリカ フェイルオーバーのいずれの場合も、DR レプリカがプライマリ インスタンスに昇格し、昇格したインスタンスで PITR を使用する場合は、PITR を手動で有効にする必要があります。

PITR を有効にすると、バックアップ構成とトランザクション ログ保持ポリシーが適用されます。これらの設定に値を指定しない場合は、デフォルト値の 14 日が適用されます。

詳細については、PITR を使用するをご覧ください。

新しいプライマリ インスタンスで PITR を有効にすると、インスタンスをアクティブなプライマリ インスタンスである任意の時点に復元できます。

レプリカ フェイルオーバー中のスプリット ブレイン

レプリカ フェイルオーバーを使用してレプリカが昇格されているときに、プライマリ インスタンスが書き込みを引き続き受け入れると、スプリット ブレインが発生することがあります。レプリカが昇格された後で、古いプライマリ インスタンスが再び使用可能になると、古いプライマリ インスタンスが昇格されたインスタンスのレプリカとして再ビルドされ、最終的なバックアップが作成されます。このバックアップを使用して、昇格されたレプリカに書き込まれなかったスプリット ブレイン データを復元できます。

レプリカのバックアップとトランザクション ログの削除

PITR とバックアップで有効になっているプライマリ インスタンスがリードレプリカになると、プライマリ インスタンスとしての最後のバックアップと PITR 保持ポリシーが、レプリカとしての期間の間保持、適用されます。新しいプライマリ インスタンスがバックアップを取得していなくても、最後に構成されたポリシーに沿って、PITR に使用される古いバックアップとトランザクション ログがリードレプリカで削除されます。

たとえば、インスタンスが毎日自動バックアップを行い、7 日間の PITR ログを使用した 7 つのバックアップを保持するように構成されている場合、このインスタンスがリードレプリカになると、7 日以上経過したログは 1 日に 1 回削除されます。

バックアップをすぐに削除する必要がある場合は、バックアップを手動で削除できます。詳細については、バックアップを削除するをご覧ください。

VPC Service Controls と高度な DR に関する推奨事項

VPC Service Controls を使用する場合は、特に異なるプロジェクトの鍵で CMEK を使用する場合に、サービス境界で、特定の時点への復元（PITR）オペレーションなどのすべての復元オペレーションに必要な通信が許可されていることを確認してください。

切り替えやレプリカ フェイルオーバーなどの高度な 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 エディションのリードレプリカ インスタンスを DR レプリカとして指定することはできません。インスタンスが PITR のログを保存する場所を確認するには、PITR に使用されるトランザクション ログの保存場所を確認するをご覧ください。

  • 外部レプリカを DR レプリカとして指定することはできません。

  • Terraform は、レプリカのフェイルオーバー オペレーションではサポートされていません。

  • Google Cloud コンソールを使用して、レプリカのフェイルオーバーまたはスイッチオーバー オペレーションを実行することはできません。

トラブルシューティング

問題 トラブルシューティング
切り替えオペレーションが失敗しました。
    インスタンスが、DR レプリカ（カスケード可能なレプリカ）の要件をすべて満たしていることを確認します。
  • データベースのトランザクション量を確認します。トランザクションの量が多いと、オペレーションがタイムアウトする可能性があります。トランザクションの負荷が少ないときにオペレーションを再試行することを検討してください。
切り替えオペレーションが失敗し、プライマリ インスタンスが読み取り専用モードのまま停止しています。 データベースを再起動して、プライマリ インスタンスを書き込みモードに戻します。
切り替えオペレーションは完了しましたが、 Google Cloud コンソールにインスタンスの新しい入れ替え済みのロールが表示されません。 ブラウザを更新すると、更新されたトポロジが表示されます。
レプリカのフェイルオーバー オペレーションを実行できませんでした。
  • プライマリ インスタンスの DR レプリカが作成され、DR レプリカがオンラインになっていることを確認します。
  • DR レプリカへのフェイルオーバーが失敗した場合、代わりに通常の（非 DR の）リードレプリカにプロモートします。

次のステップ