災害対策および Amazon Aurora グローバルデータベース - Amazon Aurora

災害対策および Amazon Aurora グローバルデータベース

Aurora グローバルデータベースは、デフォルトの Aurora DB クラスターで提供されるフェイルオーバーよりも包括的なフェイルオーバー機能を提供します。Aurora グローバルデータベースを使用することにより、災害に対する計画と復旧をかなり迅速に実行できます。災害からの復旧は、通常、RTO と RPO (目標復旧時点) の値を使用して測定します。

  • 目標復旧時間 (RTO) – 災害後にシステムが稼働状態に戻るまでにかかる時間。つまり、RTO はダウンタイムを測定します。Aurora グローバルデータベースの場合、RTO は分単位で行えます。

  • 目標復旧時点 (RPO) – 損失する可能性があるデータの量 (時間単位)。Aurora グローバルデータベースの場合、RPO (目標復旧時点) は通常、秒単位で測定されます。Aurora PostgreSQL – ベースのグローバルデータベースでは、rds.global_db_rpo パラメータを使用して RPO の上限を設定および追跡できますが、そうすると、プライマリクラスターの読み取りノードでのトランザクション処理に影響を与える可能性があります。詳細については、Aurora PostgreSQL– ベースのグローバルデータベースの RPO (目標復旧時点) 管理 を参照してください。

Aurora グローバルデータベースでは、フェイルオーバーに対する 2 つの異なるアプローチから選択できます。

  • 管理された計画済みのフェイルオーバー – この機能は、災害復旧 (DR) のテストシナリオ、運用メンテナンス、その他の計画された運用手順など、管理された環境を対象としています。管理された計画済みのフェイルオーバーにより、Aurora グローバルデータベースのプライマリ DB クラスターをセカンダリリージョンの 1 つに再配置できます。この機能は、他の変更を行う前にセカンダリ DB クラスターとプライマリクラスターを同期するため、RPO は 0 (データの損失なし) になります。降格、昇格、およびすべての同期が処理されるため、この自動プロセスの RTO (目標復旧回復) は、通常「デタッチと昇格」フェイルオーバープロセスよりも小さくなります。詳細については、「Amazon Aurora グローバルデータベースの計画的なフェイルオーバを管理する」を参照してください。

  • 予期しないフェイルオーバー (「デタッチと昇格」) – 予期しない停止から回復するには、Aurora グローバルデータベース内のセカンダリの 1 つへのクロスリージョンフェイルオーバーを実行できます。この手動プロセスの RTO (目標復旧時間) は、予期しない停止からの Amazon Aurora グローバルデータベースの復旧 に示すタスクの実行速度によって異なります。通常、RPO (目標復旧時点) は秒単位で測定されますが、これは障害発生時のネットワーク経由での Aurora ストレージレプリケーションの遅延によって異なります。

Amazon Aurora グローバルデータベースの計画的なフェイルオーバを管理する

管理された計画済みのフェイルオーバーを使用すると、Aurora グローバルデータベースのプライマリクラスターを定期的に別の AWS リージョンに再配置できます。本稼働システムでこの機能を実証できることは、政府機関、金融機関、その他多くの規制対象業界にとっての法的要件です。この機能は、災害復旧 (DR) テストシナリオ、運用メンテナンス、その他の計画された運用手順など、管理された環境を対象としています。

たとえば、ニューヨークに本社を置く金融機関が、サンフランシスコ、英国、欧州に支店を構えているとします。組織のコアビジネスアプリケーションは、Aurora グローバルデータベースを使用します。そのプライマリクラスターは 米国東部 (オハイオ) リージョン で実行され、セカンダリクラスターは 米国西部 (北カリフォルニア) リージョン、欧州 (ロンドン) リージョン、欧州 (フランクフルト) リージョン で実行されます。四半期ごとに、プライマリクラスターを (現在の) プライマリ AWS リージョンから、その回転用に指定されたセカンダリリージョンに再配置します。

すべての組織が、Aurora グローバルデータベースのプライマリクラスターを定期的にローテーションしなければならないわけではありません。ただし、規制当局による監査中にこれを行う能力は、災害復旧要件を満たすための重要な要件です。災害復旧準備のベストプラクティスとして、あらゆるタイプの組織に対して、管理された計画済みのフェイルオーバーを管理することをお勧めします。これにより、手順が完全かつ正確であることが保証されるだけでなく、さらに重要な点として、DR フェイルオーバーが実際に発生する前に実行するようにスタッフをトレーニングします。

注記

管理された計画済みのフェイルオーバーは、正常な Aurora グローバルデータベースで使用するように設計されています。予期しない停止から復旧するには、予期しない停止からの Amazon Aurora グローバルデータベースの復旧 に記載されている「デタッチと昇格」プロセスに従います。

管理された計画済みの済みのフェイルオーバー中、プライマリクラスターは選択したセカンダリリージョンにフェイルオーバーされ、Aurora グローバルデータベースの既存のレプリケーショントポロジが維持されます。管理された計画済みのフェイルオーバープロセスが開始する前に、Aurora グローバルデータベースはすべてのセカンダリクラスターをそのプライマリクラスターと同期します。すべてのクラスターが同期されたことを確認すると、管理されたフェイルオーバーが開始されます。プライマリリージョンの DB クラスターが読み取り専用になります。選択したセカンダリクラスターは、読み取り専用ノードの 1 つを完全な読み取り状態に昇格し、クラスターがプライマリクラスターのロールを引き受けることができます。プロセスの開始時にすべてのセカンダリクラスターがプライマリと同期されているため、新しいプライマリは、データを失うことなく、Aurora グローバルデータベースの操作を続行します。プライマリクラスターと選択したセカンダリクラスターが新しいロールを引き受けるため、短時間アプリケーションを使用できなくなります。

アプリケーションの可用性を最適化するには、この機能を使用する前に、次の操作を行うことをお勧めします。

  • この操作は、ピーク時以外に、またはプライマリ DB クラスターへの書き込みが最小限である別の時間に実行します。

  • アプリケーションをオフラインにして、Aurora グローバルデータベースのプライマリクラスターへの書き込みが送信されないようにします。

  • Aurora グローバルデータベース内のすべてのセカンダリ Aurora DB クラスターのラグタイムを確認します。管理された計画済みのフェイルオーバーの全体的なラグタイムが最も少ない時間を選択します。Amazon CloudWatch を使用して、すべてのセカンダリに対する AuroraGlobalDBReplicationLag メトリクスを表示します。このメトリクスは、セカンダリがプライマリ DB クラスターでどのくらい遅れているか (ミリ秒単位) を示します。その値は、Aurora がフェイルオーバーの完了までにかかる時間に正比例します。つまり、ラグ値が大きいほど停止時間が長くなるため、ラグの少ないリージョンを選択してください。

    Aurora 向け CloudWatch メトリクスの詳細については、Amazon Aurora のクラスターレベルのメトリクス を参照してください。

管理された計画済みフェイルオーバー中、選択したセカンダリ DB クラスターは、プライマリとして新しいロールに昇格されます。ただし、プライマリ DB クラスターのさまざまな設定オプションは継承されません。構成の不一致は、パフォーマンスの問題、ワークロードの非互換性、およびその他の異常な動作につながる可能性があります。このような問題を回避するには、Aurora グローバルデータベースクラスター間の次の違いを解決することをお勧めします。

  • 新しいプライマリの Aurora DB クラスターパラメータグループの構成 (必要な場合) – Aurora グローバルデータベースの Aurora クラスターごとに Aurora DB クラスターパラメータグループを個別に設定できます。つまり、セカンダリ DB クラスターを昇格してプライマリロールを引き継ぐ場合、セカンダリからのパラメータグループは、プライマリとは異なる設定になることがあります。その場合は、プロモートされたセカンダリ DB クラスターのパラメータグループを、プライマリクラスターの設定に適合するように変更します。この方法については、「Aurora グローバルデータベースのパラメータの修正」を参照してください。

  • 監視ツールとオプション (Amazon CloudWatch Events やアラームなど) – グローバルデータベースに必要なログ機能、アラームなどを使用して、昇格された DB クラスターの設定を行います。パラメータグループと同様に、フェイルオーバープロセス中にこれらの機能の設定がプライマリから継承されることはありません。Aurora DB クラスターとモニタリングの詳細については、Overview of monitoring Amazon Aurora を参照してください。

  • 他の AWS サービスとの統合を設定する – Aurora グローバルデータベースを AWS サービス (AWS Secrets Manager、AWS Identity and Access Management、Amazon S3、AWS Lambda など) と統合する場合は、必要に応じてこれらの設定を確認する必要があります。IAM、Amazon S3、Lambda との Aurora グローバルデータベースの統合については、Amazon Aurora グローバルデータベースと他の AWS サービスの併用 を参照してください。Secrets Manager の詳細については、「AWS リージョン間で AWS Secrets Manager のシークレットのレプリケーションを自動化する方法」を参照してください。

フェイルオーバープロセスが完了すると、昇格された Aurora DB クラスターは Aurora グローバルデータベースの書き込み操作を処理できます。アプリケーションのエンドポイントを変更して、新しいエンドポイントを使用できます。Aurora グローバルデータベースの作成時に指定された名前を受け入れた場合は、アプリケーションの昇格されたクラスターのエンドポイント文字列から -ro を削除することで、エンドポイントを変更できます。

たとえば、セカンダリクラスターのエンドポイント my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com は、そのクラスターがプライマリに昇格したときに my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com になります。

Aurora グローバルデータベースをフェイルオーバーするには、AWS マネジメントコンソール、AWS CLI、または RDS API を使用します。

Aurora グローバルデータベースでフェイルオーバープロセスを開始するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [Databases (データベース)] を選択し、フェイルオーバーしたい Aurora グローバルデータベースを見つけます。

  3. [Actions (アクション)] メニューから [Fail over global database (グローバルデータベースのフェイルオーバー)] を選択します。フェイルオーバープロセスは、次の手順でフェイルオーバーターゲットを選択するまで開始されません。この時点で、フェイルオーバーは保留中です。

    
                 Aurora グローバルデータベースのフェイルオーバープロセスの開始
    1. プライマリに昇格させたいセカンダリ Aurora DB クラスターを選択します。セカンダリ DB クラスターが使用可能である必要があります。複数のセカンダリ DB クラスターがある場合は、すべてのセカンダリについてラグ量を比較し、ラグの量が最も小さいものを選択できます。

      
                 昇格するセカンダリ DB クラスターの選択
    2. [Failover Global Database (フェイルオーバーのグローバルデータベース)] を選択して、セカンダリ DB クラスターの選択を確認し、フェイルオーバープロセスを開始します。

      ヒント

      フェイルオーバープロセスの完了には時間がかかる場合があります。処理が開始されるとキャンセルできますが、Aurora グローバルデータベースを元の設定に戻すには時間がかかる場合があります。

      
                 フェイルオーバープロセスのセカンダリクラスターセレクタと確認カード

      [Databases (データベース)] リストの [Status (ステータス)] 列には、フェイルオーバープロセス中の各 Aurora DB インスタンスと Aurora DB クラスターの状態が表示されます。

      
                 フェイルオーバが動作中です。[Status (ステータス)] 列には、プロセスの状態が表示されます。

      コンソールの上部にあるステータスバーに進行状況が表示され、[Cancel failover (フェイルオーバーのキャンセル)] オプションが提供されます。[Cancel failover (フェイルオーバーをキャンセル)] を選択した場合は、フェイルオーバーを続行するか、フェイルオーバープロセスをキャンセルするかを選択できます。

      
                 フェイルオーバーキャンセルのアラート

      フェイルオーバーをキャンセルする場合は、[Cancel failover (フェイルオーバーをキャンセル)] を選択します。

    3. [Close (閉じる)] を選択してフェイルオーバーを続け、プロンプトを閉じます。

フェイルオーバーが完了すると、次に示すように、[Databases (データベース)] リストから Aurora DB クラスターとその現在の状態を確認できます。


             フェイルオーバが動作中です。[Status (ステータス)] 列には、プロセスの状態が表示されます。

Aurora グローバルデータベースをフェイルオーバーするには

failover-global-cluster CLI コマンドを使用して、Aurora グローバルデータベースをフェイルオーバーします。コマンドを使用して、次のパラメータ値を渡します。

  • --region – Auroraグローバルデータベースのプライマリ DB クラスターが実行されている AWS リージョンを指定します。

  • --global-cluster-identifier – Aurora グローバルデータベースの名前を指定します。

  • --target-db-cluster-identfier – Aurora グローバルデータベースのプライマリに昇格する Aurora DB クラスターの Amazon リソースネーム (ARN) を指定します。

Linux、macOS、Unix の場合:

aws rds --region aws-Region \ failover-global-cluster --global-cluster-identifier global_database_id \ --target-db-cluster-identifier ARN-of-secondary-to-promote

Windows の場合:

aws rds --region aws-Region ^ failover-global-cluster --global-cluster-identifier global_database_id ^ --target-db-cluster-identifier ARN-of-secondary-to-promote

Aurora グローバルデータベースをフェイルオーバーするには、FailoverGlobalCluster API オペレーションを実行します。

Aurora PostgreSQL– ベースのグローバルデータベースの RPO (目標復旧時点) 管理

Aurora PostgreSQL – ベースのグローバルデータベースでは、PostgreSQL の rds.global_db_rpo パラメータを使用して、Aurora グローバルデータベースの目標復旧ポイント (RPO) を管理できます。RPO (目標復旧時点) は、停止時に失われる可能性があるデータの最大量を表します。

Aurora PostgreSQL – ベースのグローバルデータベースに RPO を設定する場合、Aurora はすべてのセカンダリクラスターの RPO ラグタイムを監視し、少なくとも 1 つのセカンダリクラスターがターゲット RPO ウィンドウ内に留まることを確認します。RPO ラグタイムは、もう 1 つの時間ベースのメトリクスです。

RPO は、フェイルオーバー後にデータベースが新しい AWS リージョンで操作を再開するときに使用します。Aurora は、RPO と RPO ラグタイムを評価して、プライマリでトランザクションをコミット (またはブロック) します。

  • 少なくとも 1 つのセカンダリ DB クラスターの RPO ラグタイムが RPO よりも短い場合に、トランザクションをコミットします。

  • すべてのセカンダリ DB クラスターの RPO ラグタイムが RPO よりも大きい場合、トランザクションをブロックします。また、イベントを PostgreSQL ログファイルに記録し、ブロックされたセッションを示す「待機」イベントも出力します。

つまり、すべてのセカンダリクラスターがターゲット RPO より遅れている場合、Aurora は、セカンダリクラスターの少なくとも 1 つが追いつくまでプライマリクラスターのトランザクションを一時停止します。少なくとも 1 つのセカンダリ DB クラスターのラグタイムが RPO を下回るとすぐに、再度トランザクションがコミットされます。その結果、RPO (目標復旧時点) に達するまで、トランザクションはコミットできません。

このパラメータを以下に示すように設定すると、生成されたメトリクスを監視することもできます。これを行うには、psql または別のツールを使用して、Aurora グローバルデータベースのプライマリ DB クラスターをクエリし、Aurora PostgreSQL – ベースのグローバルデータベースの操作に関する詳細情報を取得できます。この方法については、「Aurora PostgreSQL ベースの Aurora グローバルデータベースのモニタリング」を参照してください。

目標復旧時点の設定

rds.global_db_rpo パラメータは、PostgreSQL データベースの RPO 設定を制御します。このパラメータは、Aurora PostgreSQL でサポートされています。有効な値の rds.global_db_rpo 範囲は 20 秒から 2,147,483,647 秒 (68 年) です。ビジネスニーズとユースケースに合わせて、現実的な価値をお選びください。たとえば、RPO (目標復旧時点) に最大 10 分かかる場合があります。この場合、値を 600 に設定します。

この値は、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して、Aurora PostgreSQL – ベースのグローバルデータベースに設定できます。

RPO を設定するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. Aurora グローバルデータベースのプライマリクラスターを選択し、[Configuration (設定)] タブを開いて DB クラスターのパラメータグループを見つけます。たとえば、Aurora PostgreSQL 11.7 を実行するプライマリ DB クラスターのデフォルトパラメータグループは default.aurora-postgresql11 です。

    パラメータグループは直接編集できません。代わりに、以下を実行できます。

    • 適切なデフォルトパラメータグループを開始点として使用して、カスタム DB クラスターのパラメータグループを作成します。たとえば、default.aurora-postgresql11 に基づいてカスタム DB クラスターのパラメータグループを作成します。

    • カスタム DB パラメータグループで、ユースケースに合わせて rds.global_db_rpo パラメータの値を設定します。有効な値の範囲は、20 秒から最大整数値 2,147,483,647 (68 年) までです。

    • 変更した DB クラスターパラメータグループを Aurora DB クラスターに適用します。

詳細については、「DB クラスターパラメータグループのパラメータの変更」を参照してください。

rds.global_db_rpo パラメータを設定するには、modify-db-cluster-parameter-group CLI コマンドを使用します。コマンドで、プライマリクラスターのパラメータグループの名前と RPO パラメータの値を指定します。

次の例では、my_custom_global_parameter_group という名前のプライマリ DB クラスターのパラメータグループの RPO を 600 秒 (10分) に設定します。

Linux、macOS、Unix の場合:

aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name my_custom_global_parameter_group \ --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

Windows の場合:

aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name my_custom_global_parameter_group ^ --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

rds.global_db_rpo パラメータを変更するには、Amazon RDS ModifyDBClusterParameterGroup API オペレーションを使用します。

目標復旧時点の表示

グローバルデータベースの目標復旧時点 (RPO) は、各 DB クラスターの rds.global_db_rpo パラメータに保存されます。表示するセカンダリクラスターのエンドポイントに接続し、この値についてインスタンスのクエリに psql を使用できます。

db-name=>show rds.global_db_rpo;

このパラメータが設定されていない場合、クエリは次の値を返します。

rds.global_db_rpo ------------------- -1 (1 row)

この次の応答は、1 分の RPO 設定を持つセカンダリ DB クラスターからのものです。

rds.global_db_rpo ------------------- 60 (1 row)

CLI を使用して、クラスターのすべての user パラメータ値を取得することで、Aurora DB クラスターのいずれかで rds.global_db_rpo がアクティブかどうかを調べるための値を取得することもできます。

Linux、macOS、Unix の場合:

aws rds describe-db-cluster-parameters \ --db-cluster-parameter-group-name lab-test-apg-global \ --source user

Windows の場合:

aws rds describe-db-cluster-parameters ^ --db-cluster-parameter-group-name lab-test-apg-global * --source user

このコマンドは、default-engine または system DB クラスターパラメータではないすべての user パラメータについて、次のような出力を返します。

{ "Parameters": [ { "ParameterName": "rds.global_db_rpo", "ParameterValue": "60", "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.", "Source": "user", "ApplyType": "dynamic", "DataType": "integer", "AllowedValues": "20-2147483647", "IsModifiable": true, "ApplyMethod": "immediate", "SupportedEngineModes": [ "provisioned" ] } ] }

クラスターパラメータグループのパラメータ表示の詳細については、DB クラスターパラメータグループのパラメータ値を表示する を参照してください。

目標復旧時点の無効化

RPO を無効にするには、rds.global_db_rpo パラメータをリセットします。AWS マネジメントコンソール、AWS CLI、または RDS API を使用してパラメータをリセットできます。

RPO を無効にするには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[パラメータグループ] を選択します。

  3. リストで、プライマリ DB クラスターパラメータグループを選択します。

  4. [Edit parameters] を選択します。

  5. [rds.global_db_rpo] パラメータの横にあるボックスを選択します。

  6. [リセット] を選択します。

  7. 画面に [Reset parameters in DB parameter group (DB パラメータグループのパラメータのリセット)] が表示されたら、[Reset parameters (パラメータのリセット)] を選択します。

コンソールでパラメータをリセットする方法の詳細については、「DB クラスターパラメータグループのパラメータの変更」を参照してください。

rds.global_db_rpo パラメータをリセットするには、reset-db-cluster-parameter-group コマンドを使用します。

Linux、macOS、Unix の場合:

aws rds reset-db-cluster-parameter-group \ --db-cluster-parameter-group-name global_db_cluster_parameter_group \ --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

Windows の場合:

aws rds reset-db-cluster-parameter-group ^ --db-cluster-parameter-group-name global_db_cluster_parameter_group ^ --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

rds.global_db_rpo パラメータをリセットするには、Amazon RDS API ResetDBClusterParameterGroup オペレーションを使用します。

予期しない停止からの Amazon Aurora グローバルデータベースの復旧

ごくまれに、Aurora グローバルデータベースのプライマリ AWS リージョンで予期しない停止が発生することがあります。この場合、プライマリ Aurora DB クラスターとその読み取りノードを使用できなくなり、プライマリクラスターとセカンダリクラスター間のレプリケーションが停止します。ダウンタイム (RTO) とデータ損失 (RPO) の両方を最小限に抑えるため、迅速に作業を行ってリージョン間のフェイルオーバーを実行し、Aurora グローバルデータベースを再構築できます。

ヒント

このプロセスを理解してから使用することをお勧めします。リージョン全体にわたる問題の最初の兆候が見られたら、すぐに計画を進める準備をしてください。ラグタイムが最も少ないセカンダリリージョンを特定する準備が整います。セカンダリクラスターのラグタイムを追跡するには、定期的に Amazon CloudWatch を使用します。

プライマリリージョンで予期しない停止が発生した後にセカンダリクラスターにフェイルオーバーするには

  1. 停止状態で、AWS リージョンのプライマリ Aurora DB クラスターに対して DML ステートメントおよびその他の書き込み操作の発行を停止します。

  2. 新しいプライマリ DB クラスターとして使用するセカンダリ AWS リージョンから Aurora DB クラスターを特定します。Aurora グローバルデータベースに 2 つ (またはそれ以上) のセカンダリ AWS リージョンがある場合は、ラグタイムが最も少ないセカンダリクラスターを選択します。

  3. 選択したセカンダリ DB クラスターを Aurora グローバルデータベースからデタッチします。

    Aurora グローバルデータベースからセカンダリ DB クラスターを削除すると、プライマリからこのセカンダリへのレプリケーションが直ちに停止され、完全な読み取り/書き込み機能を備えたスタンドアロンのプロビジョンド Aurora DB クラスターに昇格されます。停止しているリージョン内のプライマリクラスターに関連付けられたその他のセカンダリ Aurora DB クラスターは引き続き利用可能で、アプリケーションからの呼び出しを受け付けることができます。また、リソースを使用することになります。Aurora グローバルデータベースを再作成するため、スプリットブレインなどの問題を回避するために、以下の手順で新しい Aurora グローバルデータベースを作成する前に、他のセカンダリ DB クラスターを削除します。

    アタッチ解除の詳細な手順については、Amazon Aurora グローバルデータベースからのクラスターの削除 を参照してください。

  4. 新しいエンドポイントを使用して、このスタンドアロン Aurora DB クラスターにすべての書き込み操作を送信するように、アプリケーションを再構成します。Aurora グローバルデータベースの作成時に指定された名前を受け入れた場合は、アプリケーション内のクラスターのエンドポイント文字列から -ro を削除することで、エンドポイントを変更できます。

    たとえば、セカンダリクラスターのエンドポイント my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com は、そのクラスターが Aurora グローバルデータベースからデタッチされたときに my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com になります。

    この Aurora DB クラスターは、次の手順でリージョンを追加すると、新しい Aurora グローバルデータベースのプライマリクラスターになります。

  5. DB クラスターに AWS リージョンを追加します。これを行うと、プライマリからセカンダリへのレプリケーションプロセスが開始されます。リージョンを追加する詳細な手順については、Amazon Aurora リージョンを AWS グローバルデータベースに追加する を参照してください。

  6. 必要に応じて、AWS リージョンを追加して、アプリケーションのサポートに必要なトポロジを再作成します。

Aurora グローバルデータベース内の Aurora DB クラスター間のデータの不整合を避けるために、これらの変更を行う前、最中、および後に、アプリケーションの書き込みが正しい DB クラスターに送信されていることを確認してください (スプリットブレインの問題)。

AWS リージョンの停止に応じてこの再構成を実行した場合は、管理された計画済みのフェイルオーバープロセスを使用して、停止が解決された後に、Aurora グローバルデータベースを元のプライマリ AWS リージョンに戻すことができます。Aurora グローバルデータベースでは、管理された計画済みのフェイルオーバー機能をサポートする Aurora PostgreSQL または Aurora MySQL のバージョンを使用する必要があります。詳細については、Amazon Aurora グローバルデータベースの計画的なフェイルオーバを管理する を参照してください。