予期しない停止からの Aurora Global Database の復旧 Aurora Global Database の管理された計画的なフェイルオーバーを実行する Aurora PostgreSQL- ベースのグローバルデータベースの RPO (目標復旧時点) 管理

Amazon Aurora Global Database のフェイルオーバーを使用する

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

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

Aurora Global Database では、シナリオに応じて、フェイルオーバーに対する 2 つの異なるアプローチがあります。

計画外のフェイルオーバーの手動処理 (「デタッチと昇格」) – 計画外の停止から回復したり、災害対策 (DR) のテストをしたりするには、Aurora Global Database 内のセカンダリの 1 つへのクロスリージョンフェイルオーバーを実行します。この手動プロセスの RTO (目標復旧時間) は、予期しない停止からの Amazon Aurora Global Database の復旧に示すタスクの実行速度によって異なります。通常、RPO (目標復旧時点) は秒単位で測定されますが、これは障害発生時のネットワーク経由での Aurora ストレージレプリケーションの遅延によって異なります。
管理された計画済みのフェイルオーバー – この機能は、運用メンテナンス、その他の計画された運用手順など、管理された環境を対象としています。管理された計画済みのフェイルオーバーを使用することにより、Aurora Global Database のプライマリ DB クラスターをセカンダリリージョンの 1 つに再配置できます。この機能は、他の変更を行う前にセカンダリ DB クラスターとプライマリクラスターを同期するため、RPO は 0 (データの損失なし) になります。詳細については、「Amazon Aurora Global Database の管理された計画的なフェイルオーバーを実行する」を参照してください。

注記

プライマリ DB クラスターとセカンダリ DB クラスターのメジャーバージョンとマイナーエンジンバージョンが同じである場合にのみ、Aurora グローバルデータベースでマネージドクロスリージョンデータベースフェイルオーバーを実行できます。パッチレベルは、マイナーエンジンバージョンによって異なる場合があります。詳細については、「フェイルオーバーのバージョン互換性」を参照してください。

トピック

予期しない停止からの Amazon Aurora Global Database の復旧
Amazon Aurora Global Database の管理された計画的なフェイルオーバーを実行する
Aurora PostgreSQL- ベースのグローバルデータベースの RPO (目標復旧時点) 管理

予期しない停止からの Amazon Aurora Global Database の復旧

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

ヒント

このプロセスを理解してから使用することをお勧めします。リージョン全体にわたる問題の初期の兆候が見られたら、すぐに計画を進める準備をしてください。ラグタイムが最も少ないセカンダリリージョンを特定する準備が整います。セカンダリクラスターのラグタイムを追跡するには、定期的に Amazon CloudWatch を使用します。実際に発生する前に計画をテストして、手順が完全かつ正確であることや、スタッフが DR フェイルオーバーの実行に習熟していることを確認します。

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

停止している AWS リージョンのプライマリ Aurora DB クラスターに対する、DML ステートメントおよびその他の書き込みオペレーションの発行を停止します。
新しいプライマリ DB クラスターとして使用するために、セカンダリ AWS リージョンの Aurora DB クラスターを指定します。Aurora Global Database に 2 つ以上のセカンダリ AWS リージョンがある場合は、遅延時間が最も少ないセカンダリクラスターを選択します。
選択したセカンダリ DB クラスターを Aurora Global Database からデタッチします。

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

アタッチ解除の詳細なステップについては、Amazon Aurora Global Database からのクラスターの削除を参照してください。
新しいエンドポイントを使用して、このスタンドアロン Aurora DB クラスターにすべての書き込み操作を送信するように、アプリケーションを再構成します。Aurora Global Database の作成時に指定された名前を受け入れた場合は、アプリケーション内のクラスターのエンドポイント文字列から -ro を削除することで、エンドポイントを変更できます。

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

この Aurora DB クラスターは、次のステップでリージョンを追加すると、新しい Aurora Global Database のプライマリクラスターになります。

RDS Proxy を使用する場合、アプリケーションの書き込みオペレーションを、新しいプライマリクラスターに関連付けられているプロキシの適切な読み取り/書き込みエンドポイントにリダイレクトします。このプロキシエンドポイントは、デフォルトのエンドポイントでも、カスタムの読み取り/書き込みエンドポイントでもかまいません。詳細については、「RDS Proxy エンドポイントとグローバルデータベースの連携について」を参照してください。
DB クラスターに AWS リージョンを追加します。これを行うと、プライマリからセカンダリへのレプリケーションプロセスがスタートされます。リージョンを追加する詳細なステップについては、AWS リージョンの Amazon Aurora Global Database への追加を参照してください。
必要に応じて、AWS リージョンを追加して、アプリケーションのサポートに必要なトポロジを再作成します。

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

AWS リージョンの停止に対して再設定を実行した場合、停止状態が解消された後に、AWS リージョンをプライマリに戻すことができます。このためには、古い AWS リージョンを新しいグローバルデータベースに追加し、管理された計画済みのフェイルオーバープロセスを使用してそのロールを切り替えます。Aurora Global Database では、管理された計画的なフェイルオーバーをサポートする Aurora PostgreSQL または Aurora MySQL のバージョンを使用する必要があります。詳細については、「Amazon Aurora Global Database の管理された計画的なフェイルオーバーを実行する」を参照してください。

Amazon Aurora Global Database の管理された計画的なフェイルオーバーを実行する

管理された計画的なフェイルオーバーを使用すると、Aurora Global Database のプライマリクラスターを、定期的に別の AWS リージョンに再配置できます。この機能は、運用メンテナンス、その他の計画された運用手順など、管理された環境を対象としています。

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

注記

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

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

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

この操作は、ピーク時以外に、またはプライマリ DB クラスターへの書き込みが最小限である別の時間に実行します。
アプリケーションをオフラインにして、Aurora Global Database のプライマリクラスターへの書き込みが送信されないようにします。
Aurora Global Database 内のすべてのセカンダリ Aurora DB クラスターのラグタイムを確認します。管理された計画的なフェイルオーバーの全体的な遅延時間が最も少ないセカンダリを選択します。Amazon CloudWatch を使用して、すべてのセカンダリに対する AuroraGlobalDBReplicationLag メトリクスを表示します。このメトリクスは、セカンダリがプライマリ DB クラスターでどのくらい遅れているか (ミリ秒単位) を示します。その値は、Aurora がフェイルオーバーの完了までにかかる時間に正比例します。つまり、ラグ値が大きいほど停止時間が長くなるため、ラグの少ないリージョンを選択してください。

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

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

新しいプライマリの Aurora DB クラスターパラメータグループの構成 (必要な場合) - Aurora Global Database の Aurora クラスターごとに Aurora DB クラスターパラメータグループを個別に設定できます。つまり、セカンダリ DB クラスターを昇格してプライマリロールを引き継ぐ場合、セカンダリからのパラメータグループは、プライマリとは異なる設定になることがあります。その場合は、プロモートされたセカンダリ DB クラスターのパラメータグループを、プライマリクラスターの設定に適合するように変更します。この方法については、「Aurora Global Database のパラメータの修正」を参照してください。
モニタリングツールとオプション (Amazon CloudWatch Events やアラームなど) - グローバルデータベースに必要なログ機能、アラームなどを使用して、昇格された DB クラスターの設定を行います。パラメータグループと同様に、フェイルオーバープロセス中にこれらの機能の設定がプライマリから継承されることはありません。Aurora DB クラスターとモニタリングの詳細については、Overview of monitoring Amazon Aurora を参照してください。
他の AWS サービスとの統合を設定する - Aurora Global Database を AWS サービス (AWS Secrets Manager、AWS Identity and Access Management、Amazon S3、AWS Lambda など) と統合する場合は、それぞれに応じた設定を行う必要があります。IAM、Amazon S3、Lambda との Aurora Global Database の統合の詳細については、「Amazon Aurora Global Database を他の AWS サービスと併用する」を参照してください。Secrets Manager の詳細については、「AWS リージョン間で AWS Secrets Manager のシークレットのレプリケーションを自動化する方法」を参照してください。

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

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

RDS Proxy を使用する場合、アプリケーションの書き込みオペレーションを、新しいプライマリクラスターに関連付けられているプロキシの適切な読み取り/書き込みエンドポイントにリダイレクトします。このプロキシエンドポイントは、デフォルトのエンドポイントでも、カスタムの読み取り/書き込みエンドポイントでもかまいません。詳細については、「RDS Proxy エンドポイントとグローバルデータベースの連携について」を参照してください。

Aurora Global Database をフェイルオーバーするには AWS Management Console、AWS CLI、または RDS API を使用します。

Aurora Global Database でフェイルオーバープロセスをスタートするには

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
[Databases (データベース)] を選択し、フェイルオーバーしたい Aurora Global Database を見つけます。
[Actions] (アクション) メニューから [Fail over global database] (グローバルデータベースのフェイルオーバー) を選択します。フェイルオーバープロセスは、次のステップでフェイルオーバーターゲットを選択するまでスタートされません。この時点で、フェイルオーバーは保留中です。
1. プライマリに昇格させたいセカンダリ Aurora DB クラスターを選択します。セカンダリ DB クラスターが使用可能である必要があります。複数のセカンダリ DB クラスターがある場合は、すべてのセカンダリについてラグ量を比較し、ラグの量が最も小さいものを選択できます。
2. [Failover Global Database (フェイルオーバーのグローバルデータベース)] を選択して、セカンダリ DB クラスターの選択を確認し、フェイルオーバープロセスをスタートします。
  
  ヒント
  フェイルオーバープロセスの完了には時間がかかる場合があります。処理がスタートされるとキャンセルできますが、Aurora Global Database を元の設定に戻すには時間がかかる場合があります。
  
  [Databases (データベース)] リストの [Status (ステータス)] 列には、フェイルオーバープロセス中の各 Aurora DB インスタンスと Aurora DB クラスターの状態が表示されます。
  
  コンソールの上部にあるステータスバーに進行状況が表示され、[Cancel failover (フェイルオーバーのキャンセル)] オプションが提供されます。[Cancel failover (フェイルオーバーをキャンセル)] を選択した場合は、フェイルオーバーを続行するか、フェイルオーバープロセスをキャンセルするかを選択できます。
  
  フェイルオーバーをキャンセルする場合は、[Cancel failover (フェイルオーバーをキャンセル)] を選択します。
3. [Close (閉じる)] を選択してフェイルオーバーを続け、プロンプトを閉じます。

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

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

Aurora Global Database をフェイルオーバーするには

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

--region – Aurora Global Database のプライマリ DB クラスターが実行されている AWS リージョンを指定します。
--global-cluster-identifier - Aurora Global Database の名前を指定します。
--target-db-cluster-identifier - Aurora Global Database のプライマリに昇格する 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 Global Database をフェイルオーバーするには、FailoverGlobalCluster API オペレーションを実行します。

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

Aurora PostgreSQL - ベースのグローバルデータベースでは、PostgreSQL の rds.global_db_rpo パラメータを使用して、Aurora Global Database の目標復旧ポイント (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 Global Database のプライマリ DB クラスターをクエリし、Aurora PostgreSQL - ベースのグローバルデータベースの操作に関する詳細情報を取得できます。この方法については、「Aurora PostgreSQL ベースの Aurora Global Database のモニタリング」を参照してください。

トピック

目標復旧時点の設定
目標復旧時点の表示
目標復旧時点の無効化

目標復旧時点の設定

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

この値は、AWS Management Console、AWS CLI、または RDS API を使用して、Aurora PostgreSQL ベースのグローバルデータベースに設定します。

RPO を設定するには

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
Aurora Global Database のプライマリクラスターを選択し、[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 を使用して、クラスターのすべての rds.global_db_rpo パラメータ値を取得することで、Aurora DB クラスターのいずれかで user がアクティブかどうかを調べるための値を取得することもできます。

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

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


{
    "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 Management Console、AWS CLI、または RDS API を使用してパラメータをリセットできます。

RPO を無効にするには

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[パラメータグループ] を選択します。
リストで、プライマリ DB クラスターパラメータグループを選択します。
[Edit parameters] を選択します。
[rds.global_db_rpo] パラメータの横にあるボックスを選択します。
[リセット] を選択します。
画面に [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 オペレーションを使用します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Aurora Global Database の書き込み転送を使用する

Aurora Global Database のモニタリング