このページでは、高度な障害復旧(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 レプリカの名前。
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 では、古いプライマリ インスタンスをリードレプリカとして再作成します。
レプリカのフェイルオーバーのステータスを確認するには、各フェーズのステータスを確認します。
最初のフェーズのステータスを確認します。
コンソール
DR レプリカがスタンドアロン インスタンスに昇格されているかどうかを確認するには、次の操作を行います。
-
Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。
- 昇格した DR レプリカの名前を確認します。
- 新しいプライマリ インスタンスの [タイプ] 列に 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 日間の PITR ログを使用した 7 つのバックアップを保持するように構成されている場合、このインスタンスがリードレプリカになると、7 日以上経過したログは 1 日に 1 回削除されます。
バックアップをすぐに削除する必要がある場合は、バックアップを手動で削除できます。詳細については、バックアップを削除するをご覧ください。
制限事項
Private Service Connect を使用する Cloud SQL インスタンスでは、高度な DR はサポートされていません。高度な DR は限定公開サービス アクセスをサポートしています。
プライマリ インスタンスがポイントインタイム リカバリ(PITR)のトランザクション ログをディスクに保存している場合、Cloud SQL Enterprise Plus エディションのリードレプリカ インスタンスを DR レプリカとして指定することはできません。インスタンスが PITR のログを保存する場所を確認するには、PITR に使用されるトランザクション ログの保存場所を確認するをご覧ください。
外部レプリカを DR レプリカとして指定することはできません。
Terraform は、切り替えオペレーションやレプリカ フェイルオーバー オペレーションではサポートされていません。
- Google Cloud コンソールを使用して、レプリカのフェイルオーバーまたはスイッチオーバー オペレーションを実行することはできません。
トラブルシューティング
問題 | トラブルシューティング |
---|---|
切り替えオペレーションが失敗しました。 |
|
切り替えオペレーションが失敗し、プライマリ インスタンスが読み取り専用モードのまま停止しています。 | データベースを再起動して、プライマリ インスタンスを書き込みモードに戻します。 |
切り替えオペレーションは完了しましたが、Google Cloud コンソールにインスタンスの新しい入れ替え済みのロールが表示されません。 | ブラウザを更新すると、更新されたトポロジが表示されます。 |
レプリカのフェイルオーバー オペレーションを実行できませんでした。 |
|