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