このページは Cloud Translation API によって翻訳されました。

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

MySQL | PostgreSQL | SQL Server

このページでは、高度な障害復旧（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 レプリカ）のバックアップが作成されます。このバックアップが完了すると、新しいプライマリインスタンスでポイントインタイムリカバリ（PITR）が完全に有効になります。このバックアップは、ディスクサイズによって完了までに 5～15 分かかることがあります。PITR のカバレッジは、このバックアップが完了した後に開始されます。高度な DR で PITR を使用する際の考慮事項については、高度な DR で PITR を使用するをご覧ください。

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

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

始める前に

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

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

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

gcloud

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

gcloud sql instances switchover REPLICA_NAME

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

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

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

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

curl（Linux、macOS、Cloud Shell）

注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ユーザーアカウントで gcloud CLI にログインしているか、Cloud Shell を使用して自動的に gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell（Windows）

注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ご自分のユーザーアカウントで gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

curl（Linux、macOS、Cloud Shell）

次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell（Windows）

次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

レプリカフェイルオーバーを呼び出して 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

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

curl（Linux、macOS、Cloud Shell）

次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell（Windows）

次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

curl（Linux、macOS、Cloud Shell）

次のコマンドを実行します。

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell（Windows）

次のコマンドを実行します。

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

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

レスポンス

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

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

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

最初のフェーズのステータスを確認します。
コンソール

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 が完了したことを確認するには、インスタンスのオペレーションログでメッセージ RECONFIGURE_OLD_PRIMARY を確認します。

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

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

高度な DR で PITR を使用する

切り替えとレプリカフェイルオーバーの両方で、DR レプリカがプライマリインスタンスに昇格するとすぐに、バックアップと PITR をサポートするために次の変更が実行されます。

バックアップ構成（自動バックアップのスケジュール設定など）は、古いプライマリインスタンスから新しいプライマリインスタンスにコピーされます。

新しいプライマリインスタンスで PITR をサポートするために、新しいバックアップが取得されます。
トランザクションログ保持ポリシーが、古いプライマリインスタンスから新しいプライマリインスタンスにコピーされます。

バックアップ構成とトランザクションログ保持ポリシーの両方で、古いプライマリインスタンスから継承された設定が新しいプライマリインスタンスにおいて正しいかどうかを確認することをおすすめします。

PITR のカバレッジ開始

切り替えオペレーションの最後に、Cloud SQL は自動バックアップのスケジュールを設定し、新しいプライマリインスタンスの最初のバックアップを取得します。PITR のカバレッジをすぐに開始したい場合は、最初のバックアップが正常に完了したかどうかを確認することをおすすめします。新しく昇格されたプライマリインスタンスは、最初の自動バックアップが正常に完了した後にのみ PITR の対象となります。

インスタンスで使用可能なバックアップを表示する方法について詳しくは、バックアップのリストを表示するをご覧ください。

切り替えとレプリカフェイルオーバー中のインスタンスの PITR カバレッジ

切り替えまたはレプリカのフェイルオーバーオペレーションに参加する場合、インスタンスはリードレプリカとなります。PITR とバックアップの復元は、インスタンスがリードレプリカとプライマリインスタンスとして使用されている期間にサポートされます。

インスタンスがプライマリインスタンスだった切り替え前の時点に PITR を実行できます。切り替えオペレーションとレプリカフェイルオーバーオペレーションの両方で、新しいプライマリインスタンスが昇格するとすぐに、Cloud SQL は新しいプライマリインスタンスのベストエフォートバックアップを開始します。PITR は、このバックアップが完了した後にのみ、昇格したインスタンスで有効になります。このバックアップは、ディスクサイズによって完了までに 5 ～ 15 分かかることがあります。

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

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

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

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

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

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

制限事項

Private Service Connect を使用する Cloud SQL インスタンスでは、高度な DR はサポートされていません。高度な DR はプライベートサービスアクセスをサポートしています。
プライマリインスタンスがポイントインタイムリカバリ（PITR）のトランザクションログをディスクに保存している場合、Cloud SQL Enterprise Plus エディションのリードレプリカインスタンスを DR レプリカとして指定することはできません。インスタンスが PITR のログを保存する場所を確認するには、PITR に使用されるトランザクションログの保存場所を確認するをご覧ください。
外部レプリカを DR レプリカとして指定することはできません。
Terraform は、切り替えオペレーションやレプリカフェイルオーバーオペレーションではサポートされていません。

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

トラブルシューティング

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

次のステップ

世界中のロケーションで利用可能なすべての Google Cloud Platform サービスを確認する。
データベースのオブザーバビリティについて確認する
Cloud SQL インスタンスをモニタリングする

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

始める前に

DR レプリカを作成する

切り替えを行う

始める前に

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

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

レプリカ フェイルオーバーを呼び出して DR を実行する

始める前に

レプリカのフェイルオーバー オペレーションを実行する

gcloud

REST v1

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

REST v1beta4

curl（Linux、macOS、Cloud Shell）

PowerShell（Windows）

レスポンス

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

コンソール

gcloud

高度な DR で PITR を使用する

PITR のカバレッジ開始

切り替えとレプリカ フェイルオーバー中のインスタンスの PITR カバレッジ

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

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

制限事項

トラブルシューティング

次のステップ

レプリカフェイルオーバーを呼び出して DR を実行する

レプリカのフェイルオーバーオペレーションを実行する

切り替えとレプリカフェイルオーバー中のインスタンスの PITR カバレッジ

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

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