高度な障害復旧(DR)を使用する

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

  • レプリカ フェイルオーバーでは、リージョン障害が発生した場合、すぐにプライマリ インスタンスを DR レプリカにフェイルオーバーできます。
  • 切り替えでは、データを損失することなく、プライマリ インスタンスと DR レプリカのロールを入れ替えることができます。切り替えを使用すると、レプリカのフェイルオーバー後にデプロイを元のデプロイ状態に復元できます。また、DR をテストすることもできます。

高度な DR は、Cloud SQL Enterprise Plus エディションのインスタンスでのみサポートされています。

始める前に

Google Cloud SDK を使用する場合は、バージョン 470.0.0 以降と gcloud beta コマンドを使用する必要があります。Google Cloud SDK のバージョンを確認するには、gcloud --version を実行します。Google Cloud SDK を更新するには、gcloud components update を実行します。

Google Cloud SDK をインストールするには、gcloud CLI をインストールするをご覧ください。

DR レプリカを指定する

高度な DR を実行するには、まずクロスリージョン DR レプリカを指定する必要があります。

DR レプリカの要件

指定された DR リードレプリカは、次の要件を満たしている必要があります。

  • Cloud SQL Enterprise Plus エディション インスタンスである
  • プライマリ インスタンスと同じデータベースのメジャー バージョンとマイナー バージョンで、MySQL 8.0.31 以降を実行している
  • プライマリ インスタンスとは別のリージョンに存在している
  • 直接のリードレプリカである。カスケード レプリカにすることはできない
  • DR レプリカでは、デフォルト値の使用だけでなく、次のフラグを構成することもできない
    • replicate_do_db
    • replicate_ignore_db
    • replicate_do_table
    • replicate_wild_do_table
    • replicate_ignore_table
    • replicate_wild_ignore_table
  • PITR に使用されるトランザクション ログを Cloud Storage に保存する
  • 外部レプリカではない

DR レプリカの推奨事項

このセクションでは、DR レプリカに関する推奨事項を示します。デプロイのパフォーマンスの問題を回避するには、次の推奨事項に従ってください。

  • プライマリ インスタンスと同じディスクサイズを使用するか、自動拡張を有効にします。
  • 一貫性のある HA 構成を使用します。プライマリ インスタンスで HA を有効にする場合、DR レプリカでも HA を有効にします。
  • 一貫性のあるデータ キャッシュ構成を使用します。プライマリ インスタンスでデータ キャッシュを有効にする場合、DR レプリカでもデータ キャッシュを有効にします。
  • 切り替えまたはレプリカのフェイルオーバー オペレーションの前後に、DR レプリカに適したデータベース フラグを構成します。

DR レプリカの要件を満たすレプリカを作成する

プライマリ インスタンスに、DR レプリカの要件を満たすクロスリージョン リードレプリカがまだない場合は、作成します。

コンソール

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

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

  2. プライマリ インスタンスを見つけます。
  3. [アクション] 列で、[その他の操作] メニューをクリックします。
  4. [リードレプリカを作成] を選択します。
  5. [インスタンス ID] フィールドに、DR レプリカの名前を入力します。
  6. [データベース バージョン] フィールドでは、MySQL 8.0 がすでに選択されています。
  7. [マイナー バージョン] フィールドは、あらかじめ選択されたマイナー バージョンのままにします。DR レプリカとプライマリ インスタンスは、同じデータベースのマイナー バージョンを共有している必要があります。
  8. ページの [リージョンとゾーンの可用性の選択] セクションで、次の操作を行います。
    • プライマリ インスタンスのリージョンとは異なるリージョンを選択します。
    • 省略可。DR レプリカで [複数のゾーン] を選択します。
    • 省略可。DR レプリカのプライマリ ゾーンセカンダリ ゾーンを選択します。
  9. このページの [インスタンスのカスタマイズ] セクションで、DR レプリカの設定を更新できます。各設定の詳細については、インスタンスの設定についてのページをご覧ください。
  10. [マシンシェイプ] で、プライマリ インスタンスと同じマシンタイプを選択します。
  11. [フラグ] で、データベースに必要なフラグを構成します。
  12. [レプリカを作成する] をクリックします。

Cloud SQL により、プライマリ インスタンスのバックアップが作成され、レプリカが作成されます。プライマリのインスタンス ページに戻ります。

gcloud

DR レプリカの要件を満たすレプリカを作成するには、次のコマンドを実行します。

gcloud sql instances create REPLICA_NAME \
   --master-instance-name=PRIMARY_INSTANCE_NAME \
   --region=REPLICA_REGION_NAME \
   --database-version=DATABASE_VERSION \
   --tier=MACHINE_TYPE \
   --availability-type=AVAILABILITY_TYPE
   --edition="ENTERPRISE_PLUS"

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

  • REPLICA_NAME: DR レプリカの名前。
  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。
  • REPLICA_REGION_NAME: プライマリ インスタンスのリージョンとは異なるリージョンを指定します。
  • DATABASE_VERSION: プライマリ インスタンスのデータベースのメジャー バージョンとマイナー バージョンに一致するバージョン文字列を指定します(例: MYSQL_8_0_31)。

    データベースのメジャー バージョンとマイナー バージョンは、プライマリ レプリカと DR レプリカの両方において同じである必要があります。

  • MACHINE_TYPE: プライマリ インスタンスと同じマシンタイプを指定します。マシンタイプは、プライマリ インスタンスのマシンタイプと一致させることをおすすめします。
  • AVAILABILITY_TYPE: プライマリ インスタンスが高可用性用に構成されている場合は、高可用性を有効にするために REGIONAL を指定することをおすすめします。
  • EDITION: ENTERPRISE_PLUS を指定します。

REST v1

リクエストのデータを使用する前に、次のように置き換えます。

  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。
  • PROJECT_ID: プライマリ インスタンスと DR レプリカの Google Cloud プロジェクトの ID またはプロジェクト番号。
  • DATABASE_VERSION: バージョン文字列。プライマリ インスタンスのデータベースのメジャー バージョンとマイナー バージョンに一致する必要があります(例: MYSQL_8_0_31)。データベースのメジャー バージョンとマイナー バージョンは、プライマリ レプリカと DR レプリカの両方において同じである必要があります。
  • REPLICA_NAME: 作成する DR レプリカ インスタンスの名前。
  • REPLICA_REGION: DR レプリカ インスタンスのリージョン。レプリカのリージョンは、プライマリ インスタンスのリージョンと別にする必要があります。
  • MACHINE_TYPE: プライマリ インスタンスと同じマシンタイプを指定します。プライマリ インスタンスと同じマシンタイプを選択することをおすすめします。
  • AVAILABILITY_TYPE: プライマリ インスタンスが高可用性用に構成されている場合は、高可用性を有効にするために REGIONAL を指定することをおすすめします。

HTTP メソッドと URL:

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

リクエストの本文(JSON):

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

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

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

REST v1beta4

リクエストのデータを使用する前に、次のように置き換えます。

  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。
  • PROJECT_ID: プライマリ インスタンスと DR レプリカの Google Cloud プロジェクトの ID またはプロジェクト番号。
  • DATABASE_VERSION: バージョン文字列。プライマリ インスタンスのデータベースのメジャー バージョンとマイナー バージョンに一致する必要があります(例: MYSQL_8_0_31)。データベースのメジャー バージョンとマイナー バージョンは、プライマリ レプリカと DR レプリカの両方において同じである必要があります。
  • REPLICA_NAME: 作成する DR レプリカ インスタンスの名前。
  • REPLICA_REGION: DR レプリカ インスタンスのリージョン。レプリカのリージョンは、プライマリ インスタンスのリージョンと別にする必要があります。
  • MACHINE_TYPE: プライマリ インスタンスと同じマシンタイプを指定します。ディスクサイズは、プライマリ インスタンスのディスクサイズと一致させることをおすすめします。
  • AVAILABILITY_TYPE: プライマリ インスタンスが高可用性用に構成されている場合は、高可用性を有効にするために REGIONAL を指定することをおすすめします。

HTTP メソッドと URL:

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

リクエストの本文(JSON):

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

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

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

プライマリ インスタンスの DR レプリカを指定する

次の手順では、プライマリ インスタンスのクロスリージョン レプリカの 1 つを、切り替えまたはレプリカ フェイルオーバー用の DR レプリカとして指定する方法について説明します。

コンソール

プライマリ インスタンスに DR レプリカを指定するには、次の操作を行います。

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

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

  2. プライマリ インスタンスを見つけて選択します。プライマリ インスタンスの概要ページが表示されます。
  3. ナビゲーション メニューで [レプリカ] をクリックします。
  4. リードレプリカのリストで、DR レプリカとして指定するクロスリージョン リードレプリカを見つけます。
  5. レプリカのアクション ボタン more_vert をクリックし、[DR レプリカとして指定] を選択します。
  6. [確認] をクリックします。

gcloud

プライマリ インスタンスに DR レプリカを指定するには、次のコマンドを使用します。

gcloud beta sql instances patch PRIMARY_INSTANCE_NAME \
   --failover-dr-replica-name=REPLICA_NAME

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

  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。
  • REPLICA_NAME: DR レプリカの名前。

REST v1

リクエストのデータを使用する前に、次のように置き換えます。

  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。
  • REPLICA_NAME: DR レプリカの名前。

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

リクエストの本文(JSON):

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

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

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

REST v1beta4

リクエストのデータを使用する前に、次のように置き換えます。

  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。
  • REPLICA_NAME: DR レプリカの名前。

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

リクエストの本文(JSON):

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

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

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

DR レプリカの指定を変更する

レプリカが要件を満たしている場合、別のレプリカを DR レプリカとして指定できます。古い DR レプリカは DR レプリカの指定を失います。

コンソール

プライマリ インスタンスの DR レプリカを変更するには、次の操作を行います。

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

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

  2. プライマリ インスタンスを見つけて選択します。プライマリ インスタンスの概要ページが表示されます。
  3. ナビゲーション メニューで [レプリカ] をクリックします。
  4. リードレプリカのリストで、新しい DR レプリカとして指定するクロスリージョン リードレプリカを見つけます。
  5. レプリカのアクション ボタン more_vert をクリックし、[DR レプリカとして指定] を選択します。

gcloud

DR レプリカを変更するには、指定コマンドを再度実行し、別の DR レプリカを指定します。

REST

DR レプリカを変更するには、指定 API リクエストを再度作成し、別の DR レプリカを指定します。

DR レプリカの指定を表示する

gcloud CLI または Cloud SQL Admin API を使用して、プライマリ インスタンスに割り当てられている DR レプリカを確認できます。レプリカが DR レプリカに指定されているかどうかを確認することもできます。

プライマリ インスタンスに指定されている DR レプリカを確認するには、次の操作を行います。

コンソール

プライマリ インスタンスに指定されている DR レプリカを確認するには、次の操作を行います。

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

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

  2. プライマリ インスタンスを見つけて選択します。プライマリ インスタンスの概要ページが表示されます。
  3. ナビゲーション メニューで [レプリカ] をクリックします。
  4. リードレプリカのリストで、指定された DR レプリカの [タイプ] 列に MySQL disaster recovery replica が表示されていることを確認します。

gcloud

プライマリ インスタンスの DR レプリカとして指定されているインスタンスを確認するには、次のコマンドを使用します。

gcloud beta sql instances describe PRIMARY_INSTANCE_NAME

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

  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前

このコマンドの出力には、指定された DR レプリカを識別する failoverDrReplica という名前のフィールドが含まれています。

REST v1

リクエストのデータを使用する前に、次のように置き換えます。

  • PROJECT_ID: インスタンスが含まれている Google Cloud プロジェクトの ID またはプロジェクト番号。
  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。

HTTP メソッドと URL:

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

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

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

REST v1beta4

リクエストのデータを使用する前に、次のように置き換えます。

  • PROJECT_ID: インスタンスが含まれている Google Cloud プロジェクトの ID またはプロジェクト番号。
  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。

HTTP メソッドと URL:

GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

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

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

レプリカが DR レプリカかどうかを確認するには、次のいずれかの操作を行います。

コンソール

レプリカ インスタンスが DR レプリカかどうかを確認するには、次の操作を行います。

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

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

  2. レプリカ インスタンスを見つけます。
  3. 指定された DR レプリカの [タイプ] 列に MySQL disaster recovery replica が表示されていることを確認します。

gcloud

レプリカ インスタンスが DR レプリカかどうかを確認するには、次のコマンドを実行します。

gcloud beta sql instances describe REPLICA_NAME

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

  • REPLICA_NAME: 確認するリードレプリカの名前

レプリカが DR レプリカの場合、コマンドの出力に drReplica=true フィールドが含まれます。

REST v1

リクエストのデータを使用する前に、次のように置き換えます。

  • PROJECT_ID: インスタンスが含まれている Google Cloud プロジェクトの ID またはプロジェクト番号。
  • REPLICA_NAME: レプリカの名前。

HTTP メソッドと URL:

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

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

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

REST v1beta4

リクエストのデータを使用する前に、次のように置き換えます。

  • PROJECT_ID: インスタンスが含まれている Google Cloud プロジェクトの ID またはプロジェクト番号。
  • REPLICA_NAME: レプリカの名前。

HTTP メソッドと URL:

GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME

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

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

DR レプリカを削除する

プライマリ インスタンスから DR レプリカの指定を消去できます。ただし、プライマリ インスタンスに DR レプリカが割り当てられていない場合、切り替えまたはレプリカ フェイルオーバーを実行することはできません。

コンソール

指定された DR レプリカをプライマリ インスタンスから削除するには、次の操作を行います。

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

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

  2. プライマリ インスタンスを見つけて選択します。プライマリ インスタンスの概要ページが表示されます。
  3. ナビゲーション メニューで [レプリカ] をクリックします。
  4. リードレプリカのリストで、削除するクロスリージョン リードレプリカを見つけます。
  5. レプリカのアクション ボタン more_vert をクリックし、[DR レプリカとして削除] を選択します。
  6. [確認] をクリックします。

gcloud

DR レプリカの指定を削除するには、プライマリ インスタンスで次のコマンドを実行します。

gcloud beta sql instances patch PRIMARY_INSTANCE_NAME \
  --clear-failover-dr-replica-name

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

  • PRIMARY_INSTANCE_NAME: 指定した DR レプリカを削除するプライマリ インスタンスの名前

REST v1

リクエストのデータを使用する前に、次のように置き換えます。

  • PROJECT_ID: プライマリ インスタンスと DR レプリカの Google Cloud プロジェクトの ID またはプロジェクト番号。
  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。
  • failoverDrReplicaName フィールドを空の文字列に設定します。

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

リクエストの本文(JSON):

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

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

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

REST v1beta4

リクエストのデータを使用する前に、次のように置き換えます。

  • PROJECT_ID: プライマリ インスタンスと DR レプリカの Google Cloud プロジェクトの ID またはプロジェクト番号。
  • PRIMARY_INSTANCE_NAME: プライマリ インスタンスの名前。
  • failoverDrReplicaName フィールドを空の文字列に設定します。

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

リクエストの本文(JSON):

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

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

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

切り替えを行う

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

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

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

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

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

始める前に

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

  • DR レプリカを指定する。プライマリ インスタンスと指定された DR レプリカの間でのみ、切り替えを実行できます。
  • プライマリ インスタンスと DR レプリカがオンラインであることを確認する。
  • プライマリ インスタンスのオンデマンド バックアップを取得する。このバックアップは、予期しない障害から復旧する必要がある場合に備えて行います。

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

コンソール

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

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

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

  2. プライマリ インスタンスの指定 DR レプリカを見つけます。
  3. DR レプリカ インスタンスをクリックします。DR レプリカの [概要] ページが表示されます。
  4. [切り替え] ボタンをクリックします。
  5. [プライマリ レプリカと DR レプリカを切り替える] ページの [インスタンス ID] フィールドに、プライマリ インスタンスの名前を入力します。
  6. [切り替え] をクリックします。

gcloud

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

gcloud beta sql instances switchover REPLICA_NAME
   [--db-timeout=TIMEOUT_DURATION ]

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

  • REPLICA_NAME: プライマリ インスタンスとロールを切り替える指定 DR レプリカの名前。
  • TIMEOUT_DURATION: 省略可。インスタンスでデータベース オペレーションを完了するためのタイムアウト期間。
  • このパラメータを指定しない場合、切り替えオペレーションには 10 分のタイムアウトが含まれます。

    このタイムアウトの値を増やすには、--db-timeout パラメータを指定します。TIMEOUT_DURATION を、最大 24 時間の期間(単位記号の最初の 1 文字を含む)に置き換えます。たとえば、30 秒の場合は 30s を指定します。24 時間の場合は、24h を指定します。小数点以下 9 桁までを使用して、期間の単位の小数部を指定することもできます。たとえば、30.5 分の場合は 30.5m を指定します。

    保留中のオペレーションがない場合は、このタイムアウトの値を削減できます。

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

古いプライマリ インスタンスがオンラインに戻ると、レプリカのフェイルオーバー プロセスがバックアップを取得します。このバックアップが取得された後、古いプライマリ インスタンスは新しいプライマリ インスタンスのリードレプリカとして再作成されます。このプロセスでは、まだ Cloud Storage に保存されていない古い PITR トランザクション ログが、古いプライマリ インスタンスから削除されます。したがって、レプリカのフェイルオーバーでは、古いプライマリ インスタンスの PITR に使用されるすべてのトランザクション ログが保持されるとは限りません。

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

重要: レプリカのフェイルオーバー オペレーションを呼び出した後、新しいプライマリ インスタンスの IP アドレスを使用するようにアプリケーションを設定します。

始める前に

レプリカのフェイルオーバーを行う前に、次の操作を行います。

  • まだ指定していない場合は、DR レプリカを指定します。レプリカ フェイルオーバーは、プライマリ インスタンスと指定された DR レプリカの間でのみ実行できます。
  • DR レプリカがオンラインかつ正常であることを確認します。

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

コンソール

レプリカのフェイルオーバー オペレーションを行うには、次の操作を行います。

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

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

  2. プライマリ インスタンスの指定 DR レプリカを見つけます。
  3. DR レプリカ インスタンスをクリックします。DR レプリカの [概要] ページが表示されます。
  4. [レプリカ フェイルオーバー] ボタンをクリックします。
  5. [プライマリ レプリカと DR レプリカの間でレプリカ フェイルオーバーを実行する] ページで、[インスタンス ID] フィールドにプライマリ インスタンスの名前を入力して、オペレーションを続行することを確認します。
  6. レプリカ フェイルオーバーを開始するには、[レプリカ フェイルオーバー] をクリックします。

gcloud

DR レプリカへのレプリカ フェイルオーバーを呼び出すには、次のコマンドを使用します。

gcloud beta 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/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. 新しいプライマリ インスタンスの [タイプ] 列に MySQL 8.0 が表示されていることを確認します。

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

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

PITR のカバレッジ開始

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

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

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

切り替えまたはレプリカのフェイルオーバー オペレーションに参加する場合、インスタンスはリードレプリカとなります。PITR とバックアップの復元は、インスタンスがリードレプリカとして使用されている期間にサポートされます。切り替えイベントが発生する前の時点(インスタンスがプライマリだったとき)への PITR を実行する場合は、クローン作成コマンドを実行して、インスタンスがプライマリ インスタンスだった時点をターゲットに指定できます。インスタンスがリードレプリカだった期間への PITR をリクエストすることはできません。

特定の時点でプライマリ インスタンスがリードレプリカだったために PITR を実行できない場合は、その時点でプライマリ インスタンスだったインスタンスに対して PITR リクエストを試行する必要があります。

同様に、レプリカがプライマリ インスタンスだったときに作成されたバックアップを復元できます。インスタンスがレプリカである場合、復元コマンドでは別のスタンドアロン インスタンスをターゲットに指定する必要があり、復元コマンドをレプリカ自体に復元することはできません。

PITR リクエストに使用するインスタンスを決定するには、オペレーション リストを使用します。インスタンスのオペレーション リストは、インスタンスが切り替えまたはレプリカ フェイルオーバー オペレーションをいつ行ったか判断するのに役立ちます。

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

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

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

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

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

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

制限事項

  • Private Service Connect を使用する Cloud SQL インスタンスでは、高度な DR はサポートされていません。
  • プライマリ インスタンスがポイントインタイム リカバリ(PITR)のトランザクション ログをディスクに保存している場合、Cloud SQL Enterprise Plus エディションのリードレプリカ インスタンスを DR レプリカとして指定することはできません。インスタンスが PITR のログを保存する場所を確認するには、PITR に使用されるトランザクション ログの保存場所を確認するをご覧ください。
  • 外部レプリカを DR レプリカとして指定することはできません。

トラブルシューティング

問題 トラブルシューティング
切り替えオペレーションが失敗しました。
  • インスタンスが、DR レプリカの要件をすべて満たしていることを確認します。
  • データベースのトランザクション量を確認します。切り替えは、切り替えを実行する前に、Cloud Storage でプライマリ インスタンスのバイナリログを保護します。トランザクションの量が多いと、オペレーションがタイムアウトする可能性があります。トランザクションの負荷が少ないときにオペレーションを再試行することを検討してください。
切り替えオペレーションが失敗し、プライマリ インスタンスが読み取り専用モードのまま停止しています。 データベースを再起動して、プライマリ インスタンスを書き込みモードに戻します。
切り替えオペレーションは完了しましたが、Google Cloud コンソールにインスタンスの新しい入れ替え済みのロールが表示されません。 ブラウザを更新すると、更新されたトポロジが表示されます。
レプリカのフェイルオーバー オペレーションを実行できませんでした。
  • DR レプリカがプライマリ インスタンス用に指定され、オンラインになっていることを確認します。
  • DR レプリカへのフェイルオーバーが失敗した場合、代わりに通常の(非 DR の)リードレプリカにプロモートします。
レプリケーションが行われていないかどうかを判断できません レプリカに接続して、次のように入力します。
show slave status;
  • レプリケーションが行われている場合は、最初の列の「Slave_IO_State」に「Waiting for master to send event」が表示され、Last_IO_Error フィールドは空になります。
  • レプリケーションが行われていない場合、最初の列 "Slave_IO_State""Connecting to master" が表示されます。また、"Last_IO_Error" フィールドに "error connecting to master 'cloudsqlreplica@x.x.x.x:3306" のようなエラーが表示されます。

Cloud SQL モニタリング ダッシュボードでレプリカのレプリケーション ステータスを確認することもできます。詳細については、Cloud SQL インスタンスをモニタリングするをご覧ください。

次のエラー メッセージが表示されます。

"Instance was converted into a replica between the target PITR time and the last available base backup. PITR logs are not available for the period instance was a replica. Please clone from the instance that was primary at time %s"

インスタンスのレプリカへの切り替えが行われている期間は、PITR を実行できません。インスタンスがレプリカだった期間の PITR ログは使用できません。

  • インスタンスのオペレーションのリストを調べ、その時点でインスタンスがレプリカであったかどうかを確認します
  • オペレーションのリストを使用して、その時点でプライマリ インスタンスだったインスタンスを特定します。
  • そのインスタンスのクローンを作成して PITR を実行します。

次のエラー メッセージが表示されます。

"You can only designate a disaster recovery (DR) replica for primary instances that are storing their PITR logs in Cloud Storage. PITR logs of the instance %s are not stored in Cloud Storage"

プライマリ インスタンスは、まだトランザクション ログの保存場所を Cloud Storage に切り替えていません。トランザクション ログの保存場所が切り替わった後にもう一度試すか、別のプライマリ インスタンスに DR レプリカを指定します。

PITR に使用されるトランザクション ログの保存場所の移動について詳しくは、ポイントインタイム リカバリ(PITR)の使用をご覧ください。

次のエラー メッセージが表示されます。

"The specified failover dr replica name REPLICA_NAME must be one of the replicas of the primary instance INSTANCE_NAME

DR レプリカの指定方法と正しいコマンド構文について詳しくは、プライマリ インスタンスの DR レプリカを指定するをご覧ください。

次のステップ