リージョン移行または障害復旧のためにレプリカを昇格させる

MySQL | PostgreSQL | SQL Server

このページでは、リージョン移行または障害復旧を目的とするクロスリージョンリードレプリカ（プライマリのリージョンとは異なるリージョンで作成されたレプリカ）の使用とプロモートの方法について説明します。

概要

クロスリージョンレプリカを昇格させる一般的なシナリオは次の 2 つです。

リージョン移行: 計画に従って異なるリージョンにデータベースを移行します。
障害復旧: プライマリリージョンが利用できなくなった場合に、データベースを別のリージョンにフェイルオーバーします。

どちらの場合も、クロスリージョンレプリケーションを設定してレプリカを昇格させます。主な違いはレプリカの昇格が計画的かどうかです。リージョン移行は計画的ですが、障害復旧は計画外で、プライマリが利用不能になったため、レプリカのリージョンにフェイルオーバーし、オペレーションを継続します。

リージョン移行

クロスリージョンレプリカを使用すると、最小限のダウンタイムでデータベースを別のリージョンに移行できます。通常は、別のリージョンにレプリカを作成し、レプリケーションが完了したらレプリカを昇格させ、新しく昇格したインスタンスにクライアントをリダイレクトします。

昇格手順は、リージョン内のレプリカを昇格させる場合と同じです。以下の手順で、元のプライマリインスタンスに commit されたトランザクションが新しく昇格したインスタンスで処理されるようにします。レプリカのプロモートが完了し、新しくプロモートしたインスタンスが機能していることを確認したら、すべてのデータベースクライアントを、この新しいインスタンスに接続するように更新します。

障害復旧（DR）

クロスリージョンレプリカは、障害復旧手順の一部として使用できます。プライマリインスタンスのリージョンが使用不可能になり、これが長時間におよぶ場合に、クロスリージョンレプリカをプロモートし、別のリージョンにフェイルオーバーできます。

障害復旧の詳細については、Cloud SQL の障害復旧についてをご覧ください。

高度な障害復旧（DR）

Cloud SQL Enterprise Plus エディションを使用している場合は、カスケード可能なレプリカを作成して、高度な障害復旧（DR）の障害復旧レプリカ（DR レプリカ）として使用できます。高度な DR では、レプリカのフェイルオーバーを実行して、プライマリインスタンスを指定した DR レプリカに交換します。古いプライマリインスタンスは、プロモートされた DR レプリカのレプリカになります。レプリカのフェイルオーバーは、指定した DR レプリカに対してのみ実行できます。フェイルオーバーを行わずに、他のリードレプリカをプロモートすることもできます。

レプリカのフェイルオーバー後にデプロイを元の状態に戻し、データ損失を回避するには、切り替えを実行します。古いプライマリインスタンスは新しいプライマリインスタンスのレプリカであるため、ロールを再度切り替えて古いプライマリインスタンスを復元できます。

詳細については、高度な障害復旧（DR）をご覧ください。高度な DR はプレビュー版です。

フェイルオーバーの基準を確認する

レプリケーションは非同期のため、リージョンの停止が発生し、フェイルオーバーが試みられると、プライマリに commit されていた最近のトランザクションが失われる可能性があります（レプリカに複製されません）。プライマリインスタンスが使用不能になった場合に、（1）リージョン間のフェイルオーバーで失われたデータがあれば、そのデータ量を特定する方法と、（2）昇格したレプリカにより、できるだけ多くの新しい書き込みが反映されるようにする方法について、その手順を以下で説明します。

レプリカのレプリケーションのステータスを確認するには、SQL Server Management Studio（SSMS）の Always On 可用性グループダッシュボードを使用するか、別のツールで開くことができます。Transact-SQL の使用に関連する情報については、以下をご覧ください。

リードレプリカを昇格させる

フェイルオーバー基準が満たされていると判断したら、レプリカの一つを書き込み可能なスタンドアロンインスタンスに昇格できます。次のシナリオを考えてみます。

リージョン A（us-central1）には高可用性プライマリインスタンス（db-a-0）があります
リージョン B（us-west1）には、db-a-0 の高可用性クロスリージョンレプリカ（db-b-1）があります
リージョン C（us-east1）には、db-a-0 のクロスリージョンレプリカ（db-c-1）があります

リージョン B の db-b-1 を昇格させ、スタンドアロンの書き込み可能なインスタンスにできます。

詳しい手順については、レプリカの昇格をご覧ください。

マシンタイプが適切であることを確認する

インスタンスでの指標のモニタリング（CPU やメモリの使用量など）を行い、新しく昇格したインスタンスのマシンタイプがワークロードに適していることを確認します。新しく昇格したインスタンスが以前のプライマリインスタンスよりも小さい場合、昇格したインスタンスを元のプライマリに合わせてサイズ変更し、同じ量の負荷を処理できるようにすることをおすすめします。

昇格したインスタンスの高可用性を有効にする

障害復旧構成では、高可用性レプリカとして昇格することを目的とするレプリカを構成することをおすすめします。別の方法としては、新しく昇格したインスタンスを高可用性として構成します。リードレプリカを高可用性向けに構成しない場合、昇格させるときに高可用性のインスタンスを構成することもできます。

昇格後のリードレプリカはバックアップで自動的に構成されます。高可用性用にリードレプリカを構成する方法は、プライマリインスタンスの場合と同じです。詳細については、高可用性のインスタンスの構成をご覧ください。

追加のレプリカを再作成する

レプリカをプライマリインスタンスに昇格させた場合、元のプライマリインスタンスの他のレプリカを再作成する必要があります。たとえば、上記で使用した構成で考えてみましょう。

リージョン A（us-central1）には高可用性プライマリインスタンス（db-a-0）があります
リージョン B（us-west1）には、db-a-0 のクロスリージョンレプリカ（db-b-1）があります
リージョン C（us-east1）には、db-a-0 のクロスリージョンレプリカ（db-c-1）があります

プライマリインスタンス（db-a-0）が利用できなくなった場合、リージョン B のレプリカをプライマリに昇格できます。リージョン A と C に再びレプリカを追加するには、古いインスタンス（A の元のプライマリインスタンスと C のレプリカ）を削除し、B の新しいプライマリインスタンスから新しいリードレプリカを作成します。

結果の構成は次のようになります。

リージョン A（us-central1）にクロスリージョンレプリカ（db-a-1）があります
リージョン B（us-west1）にプライマリインスタンス（db-b-1）があります
リージョン C（us-east1）に新しいクロスリージョンレプリカ（db-c-2）があります