このページでは、リージョン移行または障害復旧を目的とするクロスリージョン リードレプリカ（プライマリのリージョンとは異なるリージョンで作成されたレプリカ）の使用とプロモートの方法について説明します。
概要
クロスリージョン レプリカを昇格させる一般的なシナリオは次の 2 つです。
- リージョン移行: 計画に従って異なるリージョンにデータベースを移行します。
- 障害復旧: プライマリ リージョンが利用できなくなった場合に、データベースを別のリージョンにフェイルオーバーします。
どちらの場合も、クロスリージョン レプリケーションを設定してレプリカを昇格させます。主な違いはレプリカの昇格が計画的かどうかです。リージョン移行は計画的ですが、障害復旧は計画外で、プライマリが利用不能になったため、レプリカのリージョンにフェイルオーバーし、オペレーションを継続します。
リージョン移行
クロスリージョン レプリカを使用すると、最小限のダウンタイムでデータベースを別のリージョンに移行できます。通常は、別のリージョンにレプリカを作成し、レプリケーションが完了したらレプリカを昇格させ、新しく昇格したインスタンスにクライアントをリダイレクトします。
昇格手順は、リージョン内のレプリカを昇格させる場合と同じです。以下の手順で、元のプライマリ インスタンスに commit されたトランザクションが新しく昇格したインスタンスで処理されるようにします。レプリカのプロモートが完了し、新しくプロモートしたインスタンスが機能していることを確認したら、すべてのデータベース クライアントを、この新しいインスタンスに接続するように更新します。
障害復旧（DR）
クロスリージョン レプリカは、障害復旧手順の一部として使用できます。プライマリ インスタンスのリージョンが使用不可能になり、これが長時間におよぶ場合に、クロスリージョン レプリカをプロモートし、別のリージョンにフェイルオーバーできます。
障害復旧の詳細については、Cloud SQL の障害復旧についてをご覧ください。
フェイルオーバーの基準を確認する
レプリケーションは非同期のため、リージョンの停止が発生し、フェイルオーバーが試みられると、プライマリに commit されていた最近のトランザクションが失われる可能性があります（レプリカに複製されません）。プライマリ インスタンスが使用不能になった場合に、（1）リージョン間のフェイルオーバーで失われたデータがあれば、そのデータ量を特定する方法と、（2）昇格したレプリカにより、できるだけ多くの新しい書き込みが反映されるようにする方法について、その手順を以下で説明します。
まず、モニタリング ダッシュボードで Lag Bytes の値を確認します。プライマリ インスタンスのリージョンでリージョン停止が発生している場合、プライマリ インスタンスに対して Lag Bytes が報告されます。
次に、レプリケーションのステータスページ（psql クライアント タブを参照）の手順に沿って、PostgreSQL クライアントでレプリカ インスタンスに接続します。指標 pg_catalog.pg_last_wal_receive_lsn() と pg_catalog.pg_last_wal_replay_lsn() に関連する手順をご覧ください。レプリカがプライマリから受信したすべてのトランザクションを処理したことを確認します。この手順により、レプリカが昇格すると、プライマリが使用不能になる前に受信したすべてのトランザクションがレプリカにより反映されます。
リードレプリカを昇格させる
フェイルオーバー基準が満たされていると判断したら、レプリカの 1 つを書き込み可能なスタンドアロン インスタンスに昇格できます。次のシナリオを考えてみます。
- リージョン 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）があります