リードレプリカをスタンドアロン DB インスタンスに昇格させる

障害復旧の実装 – プライマリ DB インスタンスに障害が発生した場合、データ復旧スキームとして、リードレプリカを昇格させることができます。このアプローチは、同期的なレプリケーション、自動障害検出、フェイルオーバーを補完します。

非同期レプリケーションの影響と制限を承知の上で、データ復旧にリードレプリカの昇格が必要と判断した場合に限り、昇格を行ってください。これを行うには、最初にリードレプリカを作成し、次にプライマリ DB インスタンスで障害をモニタリングします。障害が発生した場合、以下の作業を行います。

ストレージ設定のアップグレード — ソース DB インスタンスが推奨ストレージ設定になっていない場合は、インスタンスのリードレプリカを作成し、ストレージファイルシステム設定をアップグレードできます。このオプションは、リードレプリカのファイルシステムを適切な設定に移行させます。次に、リードレプリカをスタンドアロンインスタンスに昇格させることができます。

このオプションを使用すると、古い 32 ビットファイルシステムのストレージとファイルサイズのスケーリング制限を克服できます。詳細については、「DB インスタンスのストレージファイルシステムのアップグレード」を参照してください。

このオプションは、ソース DB インスタンスが最新のストレージ設定になっていない場合、または同じリクエスト内で DB インスタンスクラスを変更する場合にのみ使用できます。

シャーディング – シャーディングでは、「share-nothing」アーキテクチャを採用しており、基本的に大きいデータベースが複数の小さいデータベースに分割されます。データベースを分割する一般的な方法としては、同じクエリに結合されていないテーブルを切り離して別のホスト上に配置します。別の方法としては、複数のホスト間でテーブルを複製し、ハッシュアルゴリズムを使用してどのホストで特定の更新を受け取るかを指定します。各シャード (小さいデータベース) に対応するリードレプリカを作成し、スタンドアロンシャードに変換することを決定したら昇格させることができます。次に、要件に応じて、各シャードのテーブルのキースペース (行を分割する場合) または分布を分割できます。

DDL 操作の実行 (MySQL および MariaDB のみ) – インデックスの作成や再構築などの DDL 操作には時間がかかることがあり、DB インスタンスのパフォーマンスが大幅に低下する可能性があります。これらのオペレーションは、MySQL リードレプリカや MariaDB リードレプリカがプライマリ DB インスタンスと同期されたら、これらのリードレプリカに対して実行できます。次に、リードレプリカを昇格させ、昇格されたインスタンスを使用するようにアプリケーションに指示できます。

スタンドアロン DB インスタンスは、昇格前のリードレプリカのオプショングループとパラメータグループを保持します。

新しい DB インスタンスからリードレプリカを作成して、ポイントインタイム復元オペレーションを実行できます。

昇格した DB インスタンスはリードレプリカではなくなったため、レプリケーションターゲットとしては使用できません。

バックアップ戦略を確認します。

プライマリ DB インスタンスに対するトランザクションの書き込みを停止し、すべての更新がリードレプリカに反映されるまで待ちます。

データベースの更新は、プライマイ DB インスタンスで行われた後にリードレプリカで行われます。レプリケーションのラグは大きく異なる可能性があります。Replica Lag メトリクスを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。

(MySQL および MariaDB のみ) MySQL または MariaDB のリードレプリカに変更を加えるには、リードレプリカの DB パラメータグループで read_only パラメータを 0 に設定する必要があります。次に、インデックスの作成など、必要なすべての DDL 操作をリードレプリカで実行します。リードレプリカに対するアクションの実行は、プライマリ DB インスタンスのパフォーマンスには影響しません。