# Amazon Aurora Global Database でのスイッチオーバーまたはフェイルオーバーの使用
Aurora Global Database 機能は、単一の AWS リージョンで Aurora DB クラスターが提供する標準の[高可用性](Concepts.AuroraHighAvailability.md)よりも、ビジネス継続性とディザスタリカバリ (BCDR) 保護を強化します。Aurora Global Database を使用すると、計画外のまれなリージョンディザスタやサービスレベルの完全な停止からの迅速なリカバリを計画できます。
以下のガイダンスと手順を参照して、Aurora Global Database 機能を使用した BCDR 戦略を計画、テスト、実装できます。
**Topics**
+ [ビジネス継続性とディザスタリカバリの計画](#aurora-global-database-bcdr-planning)
+ [Amazon Aurora Global Database に対するスイッチオーバーの実行](#aurora-global-database-disaster-recovery.managed-failover)
+ [予期しない停止からの Amazon Aurora Global Database の復旧](#aurora-global-database-failover)
+ [Aurora PostgreSQL- ベースのグローバルデータベースの RPO (目標復旧時点) 管理](#aurora-global-database-manage-recovery)
+ [Global Database のセカンダリクラスターのクロスリージョンの回復性](aurora-global-database-secondary-availability.md)
## ビジネス継続性とディザスタリカバリの計画
ビジネス継続性とディザスタリカバリ戦略を計画するには、以下の業界用語と、これらの用語が Aurora Global Database 機能にどのように関連するかを理解しておくと便利です。
災害からの復旧は、通常、次の 2 つのビジネス目標によって推進されます。
+ **目標復旧時間 (RTO)** - 災害またはサービス障害後にシステムが稼働状態に戻るまでにかかる時間。つまり、RTO はダウンタイムを測定します。Aurora Global Database の場合、RTO は分単位になります。
+ **目標復旧時点 (RPO)** - 災害またはサービス障害後に損失する可能性があるデータの量 (時間単位)。このデータ損失は、通常、非同期レプリケーションの遅延が原因です。Aurora Global Database の場合、RPO (目標復旧時点) は通常、秒単位で測定されます。Aurora PostgreSQL - ベースのグローバルデータベースでは、`rds.global_db_rpo` パラメータを使用して RPO の上限を設定および追跡できますが、そうすると、プライマリクラスターの読み取りノードでのトランザクション処理に影響を与える可能性があります。詳細については、「[Aurora PostgreSQL- ベースのグローバルデータベースの RPO (目標復旧時点) 管理](#aurora-global-database-manage-recovery)」を参照してください。
Aurora Global Database でスイッチオーバーまたはフェイルオーバーを実行するには、セカンダリ DB クラスターをプライマリ DB クラスターに昇格させる必要があります。「リージョン障害」という用語は、さまざまな障害シナリオを表すためによく使用されます。最悪のシナリオとしては、数百平方マイルに及ぶ壊滅的な事象による広範囲にわたる停電が考えられます。しかし、ほとんどの停電ははるかに局所的で、影響を受けるのはクラウドサービスや顧客システムのごく一部に限られます。障害の全容を検討して、クロスリージョンフェイルオーバーが適切な解決策であることを確認し、状況に適したフェイルオーバー方法を選択してください。フェイルオーバーとスイッチオーバーのどちらを使用するかは、具体的な停止シナリオによって異なります。
+ **フェイルオーバー** — このアプローチを使用して、計画外のシステム停止から回復します。この方法では、Aurora グローバルデータベース内のセカンダリ DB クラスターの 1 つにクロスリージョンフェイルオーバーを実行します。このアプローチの RPO は、通常、秒単位で測定される 0 以外の値です。障害発生時のデータ損失の量は、AWS リージョン 全体の Aurora グローバルデータベースレプリケーションの遅延によって異なります。詳細については[予期しない停止からの Amazon Aurora Global Database の復旧](#aurora-global-database-failover)を参照してください。
+ **スイッチオーバー** — このオペレーションは、以前は「計画されたマネージドフェイルオーバー」と呼ばれていました。このアプローチは、運用上のメンテナンスやその他の計画された運用上の手順など、すべての Aurora クラスターおよびこれらとやり取りする他のサービスが正常な状態にあることを確認する制御されたシナリオで使用します。この機能は、他の変更を行う前にセカンダリ DB クラスターとプライマリクラスターを同期するため、RPO は 0 (データの損失なし) になります。詳細については[Amazon Aurora Global Database に対するスイッチオーバーの実行](#aurora-global-database-disaster-recovery.managed-failover)を参照してください。
**注記**
ヘッドレスセカンダリ Aurora DB クラスターへのスイッチオーバーやフェイルオーバーを実行する前に、そのクラスターに DB インスタンスを追加する必要があります。ヘッドレス DB クラスターの詳細については、「[セカンダリリージョンでのヘッドレス Aurora DB クラスターの作成](aurora-global-database-attach.console.headless.md)」を参照してください。
## Amazon Aurora Global Database に対するスイッチオーバーの実行
**注記**
スイッチオーバーは、以前は「**計画されたマネージドフェイルオーバー**」と呼ばれていました。
スイッチオーバーを使用すると、プライマリクラスターのリージョンを定期的に変更できます。この機能は、運用メンテナンス、その他の計画された運用手順など、管理されたシナリオを対象としています。
スイッチオーバーを使用する一般的なユースケースは 3 つあります。
+ 特定の業界に課せられる「リージョナルローテーション」要件向け。たとえば、金融サービス規制では、ディザスタリカバリ手順が定期的に実施されるように、Tier-0 システムを別の地域に数か月間切り替えることが求められる場合があります。
+ マルチリージョンの「follow-the-sun」アプリケーション向け。たとえば、ある企業が、さまざまなタイムゾーンの営業時間に基づいて、さまざまなリージョンで低レイテンシーの書き込みを提供したいとします。
+ データ損失ゼロの方法として、フェイルオーバー後に元のプライマリリージョンにフェイルバックします。
**注記**
スイッチオーバーは、すべての Aurora クラスターおよびこれらがやり取りする他のサービスが正常な状態である Aurora Global Database に対して使用するように設計されています。予期しないシステム停止から回復するには、[予期しない停止からの Amazon Aurora Global Database の復旧](#aurora-global-database-failover) の該当する手順に従ってください。
Aurora Global Database でマネージドクロスリージョンスイッチオーバーを実行できるのは、プライマリ DB クラスターとセカンダリ DB クラスターが同じメジャーおよびマイナーエンジンバージョンを使用している場合のみです。パッチレベルは、エンジンとエンジンバージョンに応じて、同じである必要がある場合と、異なっても構わない場合があります。プライマリクラスターとセカンダリクラスターの間でパッチレベルが異なる場合に、これらのオペレーションを許可するエンジンとエンジンバージョンのリストについては、「[マネージドクロスリージョンスイッチオーバーまたはフェイルオーバーに対するパッチレベルの互換性](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility)」を参照してください。スイッチオーバーを開始する前に、グローバルクラスター内のエンジンバージョンをチェックして、マネージドクロスリージョンスイッチオーバーをサポートしていることを確認し、必要に応じてアップグレードしてください。
スイッチオーバーを通じて、Aurora は選択したセカンダリリージョンのクラスターをプライマリクラスターにします。スイッチオーバーメカニズムは、グローバルデータベースの既存のレプリケーショントポロジを維持します。つまり、同じリージョンに引き続き同じ数の Aurora クラスターを保持します。スイッチオーバープロセスを開始する前に、Aurora はターゲットセカンダリリージョンクラスターがプライマリリージョンクラスターと完全に同期されるまで待ちます。次に、プライマリリージョンの DB クラスターが読み取り専用になります。選択したセカンダリクラスターは、読み取り専用ノードの 1 つを完全なライターステータスに昇格し、セカンダリクラスターがプライマリクラスターのロールを引き受けられるようにします。プロセスのスタート時にターゲットセカンダリクラスターがプライマリと同期されているため、新しいプライマリは、データを失うことなく、Aurora Global Database の操作を続行します。プライマリクラスターと選択したセカンダリクラスターが新しいロールを引き受ける間、短時間データベースが使用できなくなります。
**注記**
スイッチオーバーの実行後に Aurora PostgreSQL のレプリケーションスロットを管理するには、「[Aurora PostgreSQL の論理スロットの管理](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)」を参照してください。
アプリケーションの可用性を最適化するには、この機能を使用する前に、次の操作を行うことをお勧めします。
+ この操作は、ピーク時以外に、またはプライマリ DB クラスターへの書き込みが最小限である別の時間に実行します。
+ Aurora Global Database 内のすべてのセカンダリ Aurora DB クラスターのラグタイムを確認します。すべての Aurora PostgreSQL ベースのグローバルデータベース、およびエンジンバージョン 3.04.0 以降、または 2.12.0 以降の Aurora MySQL ベースのグローバルデータベースについては、Amazon CloudWatch を使用してすべてのセカンダリ DB クラスターの `AuroraGlobalDBRPOLag` メトリクスを確認します。Aurora MySQL ベースのグローバルデータベースの下位マイナーバージョンについては、代わりに `AuroraGlobalDBReplicationLag` メトリクスを確認します。これらのメトリクスは、セカンダリクラスターがプライマリ DB クラスターに対してどのくらい遅れているか (ミリ秒単位) を示します。この値は、Aurora がスイッチオーバーを完了するまでにかかる時間に正比例します。したがって、遅延値が大きいほど、スイッチオーバーにかかる時間は長くなります。これらのメトリクスを調べるときは、現在のプライマリクラスターから行います。
Aurora 向け CloudWatch メトリクスの詳細については、「[Amazon Aurora のクラスターレベルのメトリクス](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters)」を参照してください。
+ スイッチオーバーを通じて昇格されたセカンダリ DB クラスターは、古いプライマリ DB クラスターとは構成設定が異なる場合があります。Aurora Global Database のすべてのクラスターで、以下のタイプの構成設定を一貫して維持するようお勧めします。これにより、スイッチオーバー後のパフォーマンスの問題、ワークロードの非互換性、その他の異常な動作を最小限に抑えることができます。
+ **新しいプライマリの Aurora DB クラスターパラメータグループを設定する (必要な場合)** – セカンダリ DB クラスターを昇格させてプライマリロールを引き継ぐ場合、セカンダリのパラメータグループがプライマリとは異なる設定になることがあります。その場合は、プロモートされたセカンダリ DB クラスターのパラメータグループを、プライマリクラスターの設定に適合するように変更します。この方法については、「[Aurora Global Database のパラメータの修正](aurora-global-database-modifying.parameters.md)」を参照してください。
+ **モニタリングツールとオプション (Amazon CloudWatch Events やアラームなど)** - グローバルデータベースに必要なログ機能、アラームなどを使用して、昇格された DB クラスターの設定を行います。パラメータグループと同様に、スイッチオーバープロセス中にこれらの機能の設定がプライマリから継承されることはありません。レプリケーションラグなどの一部の CloudWatch メトリクスは、セカンダリリージョンのみで使用できます。そのため、スイッチオーバーによってメトリクスの表示方法やアラームの設定方法が変わり、定義済みのダッシュボードを変更する必要が生じる場合があります。Aurora DB クラスターおよびモニタリングの詳細については、「[Amazon CloudWatch を使用した Amazon Aurora メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。
+ **他の 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 サービスと併用する](aurora-global-database-interop.md)」を参照してください。Secrets Manager の詳細については、「[AWS リージョン 間で AWS Secrets Manager のシークレットのレプリケーションを自動化する方法](https://aws.amazon.com/blogs/security/how-to-automate-replication-of-secrets-in-aws-secrets-manager-across-aws-regions/)」を参照してください。
Aurora Global Database ライターエンドポイントを使用している場合、アプリケーションの接続設定を変更する必要はありません。DNS の変更が反映されていること、および新しいプライマリクラスターに接続して書き込みオペレーションを実行できることを確認します。その後、アプリケーションの完全なオペレーションを再開できます。
アプリケーション接続で、グローバルライターエンドポイントではなく、古いプライマリクラスターのクラスターエンドポイントを使用しているとします。この場合は、新しいプライマリクラスターのクラスターエンドポイントを使用するようにアプリケーション接続の設定を変更してください。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 エンドポイントとグローバルデータベースの連携について](rds-proxy-gdb.md#rds-proxy-gdb.endpoints)」を参照してください。
Aurora Global Database のスイッチオーバーは、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して実行できます。
### コンソール
**Aurora グローバルデータベースでスイッチオーバーを実行するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. **[データベース]** を選択し、スイッチオーバーを実行する Aurora グローバルデータベースを見つけます。
1. **[アクション]** メニューから **[グローバルデータベースのスイッチオーバーまたはフェイルオーバー]** を選択します。
![\[[データベース] リストの開いている [アクション] メニューに表示されたスイッチオーバーまたはフェイルオーバーのグローバルデータベースオプション。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-switchover-1.png)
1. **[スイッチオーバー]** を選択します。
![\[[フェイルオーバー (データ損失を許可)] が選択された [グローバルデータベースのスイッチオーバーまたはフェイルオーバー] ダイアログ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-switchover-2.png)
1. **新しいプライマリクラスタ** の場合、セカンダリ AWS リージョン の 1 つで新しいプライマリクラスターになるアクティブなクラスターを選択してください。
1. **[確認]** を選択してください。
スイッチオーバーが完了すると、次の画像に示すように、**[データベース]** リストから Aurora DB クラスターとその現在のロールを確認できます。
![\[グローバルデータベースが選択された状態で Databases リストを表示します。これで、選択したセカンダリクラスターがプライマリクラスターの役割を持ち、古いプライマリクラスターがセカンダリクラスターの役割を持つように表示されます。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-switchover-3.png)
### AWS CLI
**Aurora グローバルデータベースでスイッチオーバーを実行するには**
`[switchover-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-global-cluster.html)` 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 region_of_primary \
switchover-global-cluster --global-cluster-identifier global_database_id \
--target-db-cluster-identifier arn_of_secondary_to_promote
```
Windows の場合:
```
aws rds --region region_of_primary ^
switchover-global-cluster --global-cluster-identifier global_database_id ^
--target-db-cluster-identifier arn_of_secondary_to_promote
```
### RDS API
Aurora Global Database のスイッチオーバーを行うには、[SwitchoverGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverGlobalCluster.html) API オペレーションを実行します。
## 予期しない停止からの Amazon Aurora Global Database の復旧
まれに、Aurora Global Database のプライマリ AWS リージョンで予期しない停止が発生することがあります。この場合、プライマリ Aurora DB クラスターとその読み取りノードを使用できなくなり、プライマリとセカンダリ DB クラスター間のレプリケーションが停止します。ダウンタイム (RTO) とデータ損失 (RPO) の両方を最小限に抑えるため、迅速に作業を行ってリージョン間のフェイルオーバーを実行できます。
Aurora Global Database には、ディザスタリカバリ状況で使用できるフェイルオーバー方法が 2 つあります。
+ マネージドフェイルオーバー — ディザスタリカバリにはこの方法が推奨されます。この方法を使用すると、Aurora は古いプライマリリージョンが再び使用可能になったときに、セカンダリリージョンとしてグローバルデータベースに自動的に追加します。これにより、グローバルクラスターの元のトポロジーが維持されます。この方法を使用する手順については、「[Aurora Global Database のマネージドフェイルオーバーを実行する](#aurora-global-database-failover.managed-unplanned)」を参照してください。
+ 手動フェイルオーバー — この代替方法は、プライマリリージョンとセカンダリリージョンで互換性のないエンジンバージョンが稼働している場合など、マネージドフェイルオーバーを使用できない場合に使用できます。この方法を使用する手順については、「[Aurora Global Database のマニュアルフェイルオーバーを実行する](#aurora-global-database-failover.manual-unplanned)」を参照してください。
**重要**
どちらのフェイルオーバー方法でも、フェイルオーバーイベントが発生する前に選択したセカンダリにレプリケートされていなかった書き込みトランザクションデータが失われる可能性があります。ただし、選択したセカンダリ DB クラスター上の DB インスタンスをプライマリライター DB インスタンスに昇格させるリカバリプロセスにより、データがトランザクション的に一貫した状態になることが保証されます。フェイルオーバーは、*スプリットブレイン*の問題の影響を受けやすくなります。
### Aurora Global Database のマネージドフェイルオーバーを実行する
このアプローチは、真の地域災害やサービスレベルの全面的な停止が発生した場合でも事業を継続できるようにするためのものです。
マネージドフェイルオーバーを通じて、選択したセカンダリリージョンのセカンダリクラスターは新しいプライマリクラスターになります。選択したセカンダリクラスターは、読み取り専用ノードの 1 つを完全な読み取り状態に昇格します。このステップにより、クラスターがプライマリクラスターのロールを引き受けることができます。クラスターが新しいロールを引き受ける間、データベースは短時間使用できなくなります。プライマリリージョンが正常になり、再び使用可能になるとすぐに、Aurora はそのリージョンをセカンダリリージョンとしてグローバルクラスターに自動的に追加します。したがって、Aurora グローバルデータベースの既存のレプリケーショントポロジは維持されます。
**注記**
フェイルオーバーの実行後に Aurora PostgreSQL のレプリケーションスロットを管理するには、「[Aurora PostgreSQL の論理スロットの管理](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)」を参照してください。
**注記**
Aurora Global Database でマネージドクロスリージョンフェイルオーバーを実行できるのは、プライマリ DB クラスターとセカンダリ DB クラスターのメジャーバージョンとマイナーエンジンバージョンが同じである場合のみです。パッチレベルは、エンジンとエンジンバージョンに応じて、同じである必要がある場合と、異なっても構わない場合があります。プライマリクラスターとセカンダリクラスターの間でパッチレベルが異なる場合に、これらのオペレーションを許可するエンジンとエンジンバージョンのリストについては、「[マネージドクロスリージョンスイッチオーバーまたはフェイルオーバーに対するパッチレベルの互換性](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility)」を参照してください。フェイルオーバーを開始する前に、グローバルクラスター内のエンジンバージョンをチェックして、マネージドクロスリージョンスイッチオーバーをサポートしていることを確認し、必要に応じてアップグレードしてください。エンジンバージョン間で同じパッチレベルが必要なのに、異なるパッチレベルを実行している場合は、「[Aurora Global Database のマニュアルフェイルオーバーを実行する](#aurora-global-database-failover.manual-unplanned)」の手順に従って手動でフェイルオーバーを実行できます。
マネージドフェイルオーバーは、選択したセカンダリリージョンと現在のプライマリリージョンの間でデータが同期されるまで待機しません。Aurora Global Database はデータを非同期的にレプリケートするため、選択したセカンダリ AWS リージョンが昇格されて完全な読み取り/書き込み機能を引き受けるまで、一部のトランザクションがレプリケートされない可能性があります。
データの一貫性を確保するために、Aurora は古いプライマリリージョンの新しいストレージボリュームを復旧後に作成します。新しいストレージボリュームを AWS リージョンに作成する前に、Aurora は障害発生時点における古いストレージボリュームのスナップショットを作成しようとします。これにより、スナップショットを復元し、欠落しているデータを復旧できます。このオペレーションが成功すると、Aurora は、このスナップショットを `rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp` という名前で AWS マネジメントコンソール のスナップショットセクションに配置します。`describe-db-cluster-snapshots` AWS CLI コマンドまたは `DescribeDBClusterSnapshots` API オペレーションを使用して、スナップショットの詳細を表示することもできます。
マネージドフェイルオーバーを開始すると、Aurora は高可用性の Aurora ストレージレイヤーを介した書き込みトラフィックも停止しようとします。このメカニズムを「書き込みフェンシング」と呼びます。このプロセスが成功すると、Aurora は書き込みの停止を知らせる RDS イベントを出力します。万一、リージョンで複数の AZ に障害が発生した場合は、書き込みフェンシングプロセスがタイムリーに成功しないことがあります。この場合、Aurora は書き込みを停止するプロセスがタイムアウトしたことを知らせる RDS イベントを出力します。古いプライマリクラスターにネットワークでアクセスできる場合、Aurora はこれらのイベントをそこに記録します。そうでない場合、Aurora は新しいプライマリクラスターにイベントを記録します。これらのイベントの詳細については、「[DB クラスターイベント](USER_Events.Messages.md#USER_Events.Messages.cluster)」を参照してください。書き込みフェンシングはベストエフォートの試行であるため、古いプライマリリージョンで書き込みが一時的に受け入れられ、スプリットブレイン問題が発生する可能性があります。
Aurora Global Database でフェイルオーバーを実行する前に、以下のタスクを完了することをお勧めします。これにより、スプリットブレインの問題が発生する可能性や、古いプライマリクラスターのスナップショットからのレプリケートされていないデータの復元を最小限に抑えられます。
+ Aurora Global Database のプライマリクラスターに書き込みが送信されないようにするには、アプリケーションをオフラインにします。
+ プライマリ DB クラスターに接続するアプリケーションがグローバルライターエンドポイントを使用していることを確認します。このエンドポイントでは、スイッチオーバーまたはフェイルオーバーの結果、新しいリージョンがプライマリクラスターになった場合でも値は同じままです。Aurora は、グローバルエンドポイントを通じて送信された書き込みオペレーションのデータ損失の可能性を最小限に抑えるための追加の保護を実装しています。グローバルライターエンドポイントの詳細については、「[Amazon Aurora Global Database への接続](aurora-global-database-connecting.md)」を参照してください。
+ グローバルライターエンドポイントを使用していて、アプリケーションまたはネットワークレイヤーが DNS 値をキャッシュしている場合は、DNS キャッシュの存続時間 (TTL) を 5 秒などの低い値に短縮します。これにより、アプリケーションは DNS の変更をグローバルライターエンドポイントにすばやく登録します。Aurora は古いプライマリリージョンでの書き込みをブロックしようとしますが、アクションが成功することは保証されません。DNS キャッシュ期間を短縮すると、スプリットブレインの問題が発生する可能性がさらに低下します。別の方法として、Aurora がグローバルライターエンドポイントの DNS 変更をいつ観測したかを知らせる RDS イベントをチェックできます。これにより、アプリケーションの書き込みトラフィックを再開する前に、アプリケーションが DNS 変更を登録したことも検証できます。
+ Aurora Global Database 内のすべてのセカンダリ Aurora DB クラスターについて遅延時間を確認します。レプリケーションの遅延が最も少ないセカンダリリージョンを選択すると、現在障害が発生しているプライマリリージョンでのデータ損失を最小限に抑えることができます。
すべてのバージョンの Aurora PostgreSQL ベースのグローバルデータベース、およびエンジンバージョン 3.04.0 以降または 2.12.0 以降の Aurora MySQL ベースのグローバルデータベースについては、Amazon CloudWatch を使用してすべてのセカンダリ DB クラスターの `AuroraGlobalDBRPOLag` メトリクスを確認します。Aurora MySQL ベースのグローバルデータベースの下位マイナーバージョンについては、代わりに `AuroraGlobalDBReplicationLag` メトリクスを確認します。これらのメトリクスは、セカンダリクラスターがプライマリ DB クラスターに対してどのくらい遅れているか (ミリ秒単位) を示します。
Aurora 向け CloudWatch メトリクスの詳細については、「[Amazon Aurora のクラスターレベルのメトリクス](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters)」を参照してください。
マネージドフェイルオーバー中、選択したセカンダリ DB クラスターは、プライマリとして新しいロールに昇格されます。ただし、プライマリ DB クラスターのさまざまな設定オプションは継承されません。構成の不一致は、パフォーマンスの問題、ワークロードの非互換性、およびその他の異常な動作につながる可能性があります。このような問題を回避するには、Aurora Global Database クラスター間の次の違いを解決することをお勧めします。
+ **新しいプライマリの Aurora DB クラスターパラメータグループを設定する (必要な場合)** - Aurora Global Database の Aurora クラスターごとに Aurora DB クラスターパラメータグループを個別に設定できます。そのため、セカンダリ DB クラスターを昇格してプライマリロールを引き継ぐ場合、セカンダリからのパラメータグループは、プライマリとは異なる設定になることがあります。その場合は、プロモートされたセカンダリ DB クラスターのパラメータグループを、プライマリクラスターの設定に適合するように変更します。この方法については、「[Aurora Global Database のパラメータの修正](aurora-global-database-modifying.parameters.md)」を参照してください。
+ **モニタリングツールとオプション (Amazon CloudWatch Events やアラームなど)** - グローバルデータベースに必要なログ機能、アラームなどを使用して、昇格された DB クラスターの設定を行います。パラメータグループと同様に、フェイルオーバープロセス中にこれらの機能の設定がプライマリから継承されることはありません。レプリケーションラグなどの一部の CloudWatch メトリクスは、セカンダリリージョンのみで使用できます。そのため、フェイルオーバーによってメトリクスの表示方法やアラームの設定方法が変わり、定義済みのダッシュボードを変更する必要が生じる場合があります。Aurora DB クラスターのモニタリングの詳細については、「[Amazon CloudWatch を使用した Amazon Aurora メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。
+ **他の 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 サービスと併用する](aurora-global-database-interop.md)」を参照してください。Secrets Manager の詳細については、「[AWS リージョン 間で AWS Secrets Manager のシークレットのレプリケーションを自動化する方法](https://aws.amazon.com/blogs/security/how-to-automate-replication-of-secrets-in-aws-secrets-manager-across-aws-regions/)」を参照してください。
通常、選択したセカンダリクラスターが数分以内に主要な役割を引き継ぎます。新しいプライマリリージョンのライター DB インスタンスが使用可能になり次第、それにアプリケーションを接続してワークロードを再開できます。Aurora が新しい主クラスターをプロモートすると、追加のセカンダリリージョンクラスターはすべて自動的に再構築されます。
Aurora グローバルデータベースは非同期レプリケーションを使用するため、各セカンダリリージョンのレプリケーションラグは異なる場合があります。Aurora はこれらのセカンダリリージョンを新しいプライマリリージョンクラスターとまったく同じポイントインタイムデータを持つように再構築します。ストレージボリュームのサイズとリージョン間の距離によっては、再構築タスクが完了するまでに数分から数時間かかることがあります。セカンダリージョンのクラスターが新しいプライマリリージョンからの再構築を完了すると、読み取りアクセスが可能になります。
新しいプライマリライターが昇格して使用可能になると、新しいプライマリリージョンのクラスターは Aurora グローバルデータベースの読み取りおよび書き込み操作を処理できるようになります。
グローバルエンドポイントを使用している場合は、アプリケーションの接続設定を変更する必要はありません。DNS の変更が反映されていること、および新しいプライマリクラスターに接続して書き込みオペレーションを実行できることを確認します。その後、アプリケーションの完全なオペレーションを再開できます。
グローバルエンドポイントを使用しない場合は、新しく昇格したプライマリ DB クラスターのクラスターエンドポイントを使用するように、アプリケーションのエンドポイントを変更します。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 エンドポイントとグローバルデータベースの連携について](rds-proxy-gdb.md#rds-proxy-gdb.endpoints)」を参照してください。
グローバルデータベースクラスターの元のトポロジを復元するために、Aurora は古いプライマリリージョンの可用性を監視します。そのリージョンが正常になり、再び使用可能になるとすぐに、Aurora はそのリージョンをセカンダリリージョンとしてグローバルクラスターに自動的に追加します。古いプライマリリージョンに新しいストレージボリュームを作成する前に、Aurora は障害発生時点で古いストレージボリュームのスナップショットを作成しようとします。これにより、欠落しているデータを回復することができます。このオペレーションが成功すると、Aurora は `rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp` という名前のスナップショットを作成します。このスナップショットは、AWS マネジメントコンソールの **[スナップショット]** セクションにあります。このスナップショットは、[DescribeDBClusterSnapshots](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterSnapshots.html) API オペレーションによって返される情報にも一覧表示されています。
**注記**
古いストレージボリュームのスナップショットは、古い主クラスターに設定されたバックアップ保持期間の対象となるシステムスナップショットです。このスナップショットを保存期間外に保存するには、スナップショットをコピーして手動スナップショットとして保存できます。価格などのスナップショットのコピーの詳細については、「[DB クラスタースナップショットのコピー](aurora-copy-snapshot.md)」を参照してください。
元のトポロジが復元されたら、ビジネスとワークロードにとって最も都合のよいときにスイッチオーバー操作を実行することで、グローバルデータベースを元のプライマリリージョンにフェイルバックできます。これを行うには、「[Amazon Aurora Global Database に対するスイッチオーバーの実行](#aurora-global-database-disaster-recovery.managed-failover)」の手順を実行します。
Aurora Global Database でのフェイルオーバーは、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して実行できます。
#### コンソール
**Aurora グローバルデータベースでマネージドフェイルオーバーを実行するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. **[データベース]** を選択し、フェイルオーバーを実行する Aurora グローバルデータベースを見つけます。
1. **[アクション]** メニューから **[グローバルデータベースのスイッチオーバーまたはフェイルオーバー]** を選択します。
![\[[データベース] リストの開いている [アクション] メニューに表示されたスイッチオーバーまたはフェイルオーバーのグローバルデータベースオプション。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-managed-failover-1.png)
1. **[フェイルオーバー (データ損失を許可)]** を選択します。
![\[[フェイルオーバー (データ損失を許可)] が選択された [グローバルデータベースのスイッチオーバーまたはフェイルオーバー] ダイアログ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-managed-failover-2.png)
1. **新しいプライマリクラスタ** の場合、セカンダリ AWS リージョン の 1 つで新しいプライマリクラスターになるアクティブなクラスターを選択してください。
1. **confirm** を入力して **[確認]** を選択します。
フェイルオーバーが完了すると、次の図に示すように、Aurora DB クラスターとその現在の状態を **[データベース]** リストで確認できます。
![\[グローバルデータベースが選択された状態で Databases リストを表示します。これで、選択したセカンダリクラスターがプライマリクラスターの役割を持ち、古いプライマリクラスターがセカンダリクラスターの役割を持つように表示されます。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-managed-failover-5.png)
#### AWS CLI
**Aurora グローバルデータベースでマネージドフェイルオーバーを実行するには**
`[failover-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-global-cluster.html)` CLI コマンドを使用して、Aurora Global Database でフェイルオーバーを実行します。コマンドを使用して、次のパラメータ値を渡します。
+ `--region` — Aurora グローバルデータベースの新しいプライマリにしたいセカンダリ DB クラスターが DB クラスターで実行されている AWS リージョン を指定します。
+ `--global-cluster-identifier` - Aurora Global Database の名前を指定します。
+ `--target-db-cluster-identifier` - Aurora Global Database の新しいプライマリに昇格する Aurora DB クラスターの Amazon リソースネーム (ARN) を指定します。
+ `--allow-data-loss` — これをスイッチオーバー操作ではなくフェイルオーバー操作に明示的に設定します。非同期レプリケーションコンポーネントがレプリケートされたすべてのデータをセカンダリリージョンに送信していない場合、フェイルオーバー操作によってデータの一部が失われる可能性があります。
Linux、macOS、Unix の場合:
```
aws rds --region region_of_selected_secondary \
failover-global-cluster --global-cluster-identifier global_database_id \
--target-db-cluster-identifier arn_of_secondary_to_promote \
--allow-data-loss
```
Windows の場合:
```
aws rds --region region_of_selected_secondary ^
failover-global-cluster --global-cluster-identifier global_database_id ^
--target-db-cluster-identifier arn_of_secondary_to_promote ^
--allow-data-loss
```
#### RDS API
Aurora Global Database でフェイルオーバーを行うには、[FailoverGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverGlobalCluster.html) API オペレーションを実行します。
### Aurora Global Database のマニュアルフェイルオーバーを実行する
シナリオによっては、マネージドフェイルオーバープロセスを使用できない場合があります。一例として、プライマリ DB クラスターとセカンダリ DB クラスターで互換性のあるエンジンバージョンが稼働していない場合が挙げられます。この場合、この手動プロセスに従って、ターゲットセカンダリリージョンへのフェイルオーバーを実行できます。
**ヒント**
このプロセスを理解してから使用することをお勧めします。リージョン全体にわたる問題の初期の兆候が見られたら、すぐに計画を進める準備をしてください。Amazon CloudWatch を定期的に使用してセカンダリクラスターのラグタイムを追跡することで、レプリケーションラグが最も少ないセカンダリリージョンを特定できます。実際に発生する前に計画をテストして、手順が完全かつ正確であることや、スタッフがディザスタリカバリフェイルオーバーの実行に習熟していることを確認します。
**プライマリリージョンで計画外の停止が発生した後でセカンダリクラスターへの手動フェイルオーバーを実行するには**
1. 停止している AWS リージョン のプライマリ Aurora DB クラスターに対する、DML ステートメントおよびその他の書き込みオペレーションの発行を停止します。
1. 新しいプライマリ DB クラスターとして使用するために、セカンダリ AWS リージョン の Aurora DB クラスターを指定します。Aurora Global Database に 2 つ以上のセカンダリ AWS リージョン がある場合は、レプリケーション遅延が最も少ないセカンダリクラスターを選択します。
1. 選択したセカンダリ 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-global-database-detaching.md) を参照してください。
1. 新しいエンドポイントを使用して、このスタンドアロン 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 エンドポイントとグローバルデータベースの連携について](rds-proxy-gdb.md#rds-proxy-gdb.endpoints)」を参照してください。
1. DB クラスターに AWS リージョン を追加します。これを行うと、プライマリからセカンダリへのレプリケーションプロセスがスタートされます。リージョンを追加する詳細なステップについては、[AWS リージョン の Amazon Aurora Global Database への追加](aurora-global-database-attaching.md) を参照してください。
1. 必要に応じて、AWS リージョン を追加して、アプリケーションのサポートに必要なトポロジを再作成します。
これらの変更を行う前、最中、および後に、アプリケーションの書き込みが正しい Aurora クラスターに送信されていることを確認してください。これにより、Aurora Global Database 内の DB クラスター間のデータの不整合 (*スプリットブレイン*問題) が回避されます。
AWS リージョン の停止に対して再設定を実行した場合、停止状態が解消された後に、AWS リージョン をプライマリに戻すことができます。このためには、古い AWS リージョン を新しいグローバルデータベースに追加し、スイッチオーバープロセスを使用してそのロールを切り替えます。Aurora Global Database では、スイッチオーバーをサポートする Aurora PostgreSQL または Aurora MySQL のバージョンを使用する必要があります。詳細については、「[Amazon Aurora Global Database に対するスイッチオーバーの実行](#aurora-global-database-disaster-recovery.managed-failover)」を参照してください。
## Aurora PostgreSQL- ベースのグローバルデータベースの RPO (目標復旧時点) 管理
Aurora PostgreSQL - ベースのグローバルデータベースでは、`rds.global_db_rpo` パラメータを使用して、目標復旧ポイント (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 (目標復旧時点) に達するまで、トランザクションはコミットできません。
`rds.global_db_rpo` パラメータは動的です。遅延が十分に減少するまですべての書き込みトランザクションを停止させたくない場合は、すぐにリセットできます。この場合、Aurora は少し遅れて変更を認識して実装します。
**重要**
グローバルデータベースが 2 つの AWS リージョンにしかない場合、`rds.global_db_rpo` パラメータのデフォルト値をセカンダリージョンのパラメータグループに保持しておくことをお勧めします。そうしないと、プライマリ AWS リージョンが失われてフェイルオーバーを実行すると、Aurora はトランザクションを一時停止する可能性があります。代わりに、障害が発生した古い AWS リージョンで Aurora がクラスターの再構築を完了するまで待ってから、このパラメータを変更して最大 RPO を適用してください。
このパラメータを以下に示すように設定すると、パラメータが生成するメトリクスをモニタリングすることもできます。これを行うには、`psql` または別のツールを使用して、Aurora Global Database のプライマリ DB クラスターをクエリし、Aurora PostgreSQL - ベースのグローバルデータベースの操作に関する詳細情報を取得できます。この方法については、「[Aurora PostgreSQL ベースのグローバルデータベースのモニタリング](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres)」を参照してください。
**Topics**
+ [目標復旧時点の設定](#aurora-global-database-set-rpo)
+ [目標復旧時点の表示](#aurora-global-database-view-rpo)
+ [目標復旧時点の無効化](#aurora-global-database-disable-rpo)
### 目標復旧時点の設定
`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/](https://console.aws.amazon.com/rds/)) を開きます。
1. Aurora Global Database のプライマリクラスターを選択し、[**Configuration (設定)**] タブを開いて DB クラスターのパラメータグループを見つけます。例えば、Aurora PostgreSQL 11.7 を実行するプライマリ DB クラスターのデフォルトパラメータグループは `default.aurora-postgresql11` です。
パラメータグループは直接編集できません。代わりに、以下を実行できます。
+ 適切なデフォルトパラメータグループをスタート点として使用して、カスタム DB クラスターのパラメータグループを作成します。例えば、`default.aurora-postgresql11` に基づいてカスタム DB クラスターのパラメータグループを作成します。
+ カスタム DB パラメータグループで、ユースケースに合わせて **rds.global\$1db\$1rpo** パラメータの値を設定します。有効な値の範囲は、20 秒から最大整数値 2,147,483,647 (68 年) までです。
+ 変更した DB クラスターパラメータグループを Aurora DB クラスターに適用します。
詳細については、「[Amazon Aurora での DB クラスターパラメータグループのパラメータの変更](USER_WorkingWithParamGroups.ModifyingCluster.md)」を参照してください。
#### AWS CLI
`rds.global_db_rpo` パラメータを設定するには、[modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) 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 API
`rds.global_db_rpo` パラメータを変更するには、Amazon RDS [ModifyDBClusterParameterGroup](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html) 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"
]
}
]
}
```
クラスターパラメータグループのパラメータ表示の詳細については、[Amazon Aurora での DB クラスターパラメータグループのパラメータ値の表示](USER_WorkingWithParamGroups.ViewingCluster.md) を参照してください。
### 目標復旧時点の無効化
RPO を無効にするには、`rds.global_db_rpo` パラメータをリセットします。AWS マネジメントコンソール、AWS CLI、または RDS API を使用してパラメータをリセットできます。
#### コンソール
**RPO を無効にするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**パラメータグループ**] を選択します。
1. リストで、プライマリ DB クラスターパラメータグループを選択します。
1. [**Edit parameters**] を選択します。
1. [**rds.global\$1db\$1rpo**] パラメータの横にあるボックスを選択します。
1. [**リセット**] を選択します。
1. 画面に [**Reset parameters in DB parameter group (DB パラメータグループのパラメータのリセット)**] が表示されたら、[**Reset parameters (パラメータのリセット)**] を選択します。
コンソールでパラメータをリセットする方法の詳細については、「[Amazon Aurora での DB クラスターパラメータグループのパラメータの変更](USER_WorkingWithParamGroups.ModifyingCluster.md)」を参照してください。
#### AWS CLI
`rds.global_db_rpo` パラメータをリセットするには、[reset-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/reset-db-cluster-parameter-group.html) コマンドを使用します。
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 API
`rds.global_db_rpo` パラメータをリセットするには、Amazon RDS API [ResetDBClusterParameterGroup](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ResetDBClusterParameterGroup.html) オペレーションを使用します。
# Global Database のセカンダリクラスターのクロスリージョンの回復性
Aurora PostgreSQL バージョン 16.6、15.10、14.15、13.18、12.22 以降、または Aurora MySQL バージョン 3.09 以降には、ハードウェア障害、AWS リージョンにまたがるネットワーク中断、クラスター間の大量のデータ転送など、予定外のイベントの発生時にセカンダリリージョンのリードレプリカがサービスの継続性を維持できるようにする可用性の改善が含まれています。
リードレプリカはアプリケーションリクエストで引き続き使用できますが、予定外のイベントが解決されるまでレプリケーションの遅延が長くなる可能性があります。`AuroraGlobalDBProgressLag` CloudWatch メトリクスを使用して、プライマリクラスターとセカンダリクラスター間の遅延をモニタリングできます。クラスターボリュームとセカンダリクラスターの DB インスタンス間の遅延など、エンドツーエンドの遅延を測定するには、CloudWatch メトリクスの `AuroraGlobalDBProgressLag` と `AuroraReplicaLag` の値を足します。メトリクスの詳細については、「[Amazon Aurora のメトリクスリファレンス](metrics-reference.md)」を参照してください。
Aurora MySQL 以前のバージョンの Aurora PostgreSQL の Global Database の読み取り可用性は、このような予定外のイベント中に影響を受ける可能性があります。
Aurora PostgreSQL 16.6、15.10、14.15、13.18、12.22 の新機能の詳細については、「*Aurora PostgreSQL リリースノート*」の「[PostgreSQL 16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x)」を参照してください。
Aurora MySQL バージョン 3.09 以降の詳細については、「*Aurora MySQL のリリースノート*」の「[Amazon Aurora MySQL バージョン 3 のデータベースエンジンの更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)」を参照してください。