# Amazon RDS でのマルチ AZ 配置の設定と管理
マルチ AZ デプロイには、1 つのスタンバイ DB インスタンスまたは 2 つのスタンバイ DB インスタンスを持つことができます デプロイにスタンバイ DB インスタンスが 1 つある場合は、*マルチ AZ DB インスタンスのデプロイ*と呼ばれます。マルチ AZ DB インスタンスのデプロイには、フェイルオーバーサポートを提供するスタンバイ DB インスタンスが 1 つありますが、読み取りトラフィックは処理されません。デプロイに 2 つのスタンバイ DB インスタンスが含まれている場合は、*マルチ AZ DB クラスターデプロイ*。マルチ AZ DB クラスターデプロイには、フェイルオーバーサポートを提供し、読み取りトラフィックを処理できるスタンバイ DB インスタンスがあります。
AWS マネジメントコンソール を使用して、マルチ AZ 配置がマルチ AZ DB インスタンス配置であるか、マルチ AZ DB クラスター配置であるかを特定できます。ナビゲーションペインで **[Databases]** (データベース) を選択し、**DB 識別子**を選択します。
+ マルチ AZ DB インスタンス配置には、次の特性があります。
+ DB インスタンスの行は 1 行のみ。
+ **[Role]** (ロール) の値は **[Instance]** (インスタンス) または **[Primary]** (プライマリ)。
+ **[Multi-AZ]** (マルチ AZ) の値は **[Yes]** (はい)。
+ マルチ AZ DB クラスター配置には、次の特性があります。
+ クラスターレベルの行があり、その下に 3 つの DB インスタンスの行がある。
+ クラスターレベルの行の **[Role]** (ロール) の値は **[Multi-AZ DB cluster]** (マルチ AZ DB クラスター)。
+ 各インスタンスレベルの行の **[Role]** (ロール) の値は **[Writer instance]** (ライターインスタンス) または **[Reader instance]** (リーダーインスタンス)。
+ 各インスタンスレベルの行の **[Multi-AZ]** (マルチ AZ) の値は **[3 Zones]** (3 ゾーン)。
**Topics**
+ [Amazon RDS のマルチ AZ DB インスタンスデプロイ](Concepts.MultiAZSingleStandby.md)
+ [Amazon RDS のマルチ AZ DB クラスターデプロイ](multi-az-db-clusters-concepts.md)
さらに、以下のトピックは DB インスタンスとマルチ AZ DB クラスターの両方に適用されます。
+ [ Amazon RDS リソースのタグ付け](USER_Tagging.md)
+ [Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)
+ [Amazon RDS DB インスタンスのストレージを使用する](USER_PIOPS.StorageTypes.md)
+ [DB インスタンスのメンテナンス](USER_UpgradeDBInstance.Maintenance.md)
+ [DB インスタンスのエンジンバージョンのアップグレード](USER_UpgradeDBInstance.Upgrading.md)
# Amazon RDS のマルチ AZ DB インスタンスデプロイ
Amazon RDS は、単一のスタンバイ DB インスタンスでマルチ AZ デプロイを使用して DB インスタンスの高可用性およびフェイルオーバーサポートを提供します。このタイプのデプロイは、*マルチ AZ DB インスタンスのデプロイ*と呼ばれます。Amazon RDS は複数の異なるテクノロジーを使用してフェイルオーバーサポートを提供します。MariaDB、MySQL、Oracle、PostgreSQL、および RDS Custom for SQL Server DB インスタンスのマルチ AZ デプロイでは、Amazon のフェイルオーバーテクノロジーが使用されます。Microsoft SQL Server DB インスタンスでは、SQL Server データベースのミラーリング (DBM) または Always On 可用性グループ (AGs) が使用されます。マルチ AZ の SQL Server バージョンのサポートについては、「[Amazon RDS for Microsoft SQL Server のマルチ AZ 配置](USER_SQLServerMultiAZ.md)」を参照してください。マルチ AZ の RDS Custom for SQL Server の使用については、「[RDS Custom for SQL Server のマルチ AZ 配置の管理](custom-sqlserver-multiaz.md)」を参照してください。
マルチ AZ DB インスタンスのデプロイでは、Amazon RDS は、異なるアベイラビリティーゾーンで同期スタンバイレプリカを自動的にプロビジョンおよび維持します。プライマリ DB インスタンスは、アベイラビリティーゾーン間でスタンバイレプリカに同期的に複製され、データの冗長性を提供し、システムバックアップ中の遅延スパイクを最小限に抑えます。高可用性を備えた DB インスタンスを実行すると、計画されたシステムメンテナンス中の可用性が向上する可能性があります。また、DB インスタンスの障害とアベイラビリティーゾーンの中断からデータベースを保護することを助けることもできます。アベイラビリティーゾーンの詳細については、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
**注記**
高可用性のオプションは、読み取り専用シナリオ向けのスケーリングソリューションではありません。スタンバイレプリカを使用してリードトラフィックを処理することはできません。読み取り専用トラフィックを処理するには、代わりにマルチ AZ DB クラスターまたはリードレプリカを使用します。マルチ AZ DB クラスターの詳細については、「[Amazon RDS のマルチ AZ DB クラスターデプロイ](multi-az-db-clusters-concepts.md)」を参照してください。リードレプリカの詳細については、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
![\[高可用性シナリオ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/con-multi-AZ.png)
RDS コンソールを使用すると、DB インスタンスを作成する際にマルチ AZ を指定するだけでマルチ AZ DB デプロイを作成できます。コンソールを使用し、DB インスタンスを変更し、マルチ AZ オプションを指定して、マルチ AZ DB インスタンスを変更することで、既存の DB インスタンスをマルチ AZ DBインスタンスのデプロイに変換できます。AWS CLIまたは Amazon RDS API を使用して、マルチ AZ DB インスタンスのデプロイを指定することもできます。[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) または [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンドを使用するか、[CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) または [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API オペレーションを使用します。
RDS コンソールには、スタンバイレプリカ (セカンダリ AZ と呼ばれます) のアベイラビリティーゾーンが表示されます。また、[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) CLI コマンドまたは [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) API オペレーションを使用してセカンダリ AZ を見つけることもできます。
マルチAZ DB デプロイを使用する DBインスタンスは、シングル AZ のデプロイと比較して書き込みとコミットの待ち時間が長くなる可能性があります。これは、同期データレプリケーションが発生しているために起こる可能性があります。AWS はアベイラビリティーゾーン間でのネットワーク接続レイテンシーが低くなるように設計されていますが、配置がスタンバイレプリカにフェイルオーバーした場合はレイテンシーに変化が見られる可能性があります。本番ワークロードの場合、高速で一貫したパフォーマンスを実現するために、プロビジョンドIOPS (1 秒あたりの入出力操作) を使用することをお勧めします。DB インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
# Amazon RDS の DB インスタンスをマルチ AZ 配置に変換する
DB インスタンスをマルチ AZ 配置に変更すると、別のアベイラビリティーゾーンにスタンバイインスタンスを追加することで、可用性が向上します。このプロセスではダウンタイムを最小限に抑え、ストレージとパフォーマンスへの影響について慎重に計画する必要があります。この変更により耐障害性が向上し、障害発生時の復旧時間が短縮されるため、高可用性環境に最適です。
シングル AZ デプロイの DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更すると、Amazon RDS で以下のアクションが実行されます。
1. プライマリ DB インスタンスの Amazon Elastic Block Store (EBS) ボリュームのスナップショットを作成します。
1. スナップショットからスタンバイレプリカ用の新しいボリュームを作成します。これらのボリュームはバックグラウンドで初期化され、データが完全に初期化された後に最大のボリュームパフォーマンスが得られます。
1. プライマリレプリカとスタンバイレプリカのボリューム間の同期ブロックレベルレプリケーションを有効にします。
**重要**
シングル AZ からマルチ AZ への変換中にスナップショットからスタンバイ DB インスタンスを作成すると、ダウンタイムを回避できますが、特に書き込みに敏感なワークロードではパフォーマンスに影響する可能性があります。同期レプリケーションは I/O レイテンシーを増加し、データベースのパフォーマンスに影響を与える可能性があります。ベストプラクティスとして、本番 DB インスタンスをマルチ AZ DB インスタンスに変換することは避けてください。
代わりに、リードレプリカを作成し、バックアップを有効にしてマルチ AZ に変換し、そのボリュームにデータをロードしてから、プライマリ DB インスタンスに昇格します。詳細については、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更するには 2 つの方法があります。
**Topics**
+ [RDS コンソールを使用して、マルチ AZ DB インスタンスのデプロイに変換する](#Concepts.MultiAZ.Migrating.Convert)
+ [DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更する](#Concepts.MultiAZ.Migrating.Modify)
## RDS コンソールを使用して、マルチ AZ DB インスタンスのデプロイに変換する
RDS コンソールを使用して、DB インスタンスをマルチ AZ DB インスタンスのデプロイに変換できます。
コンソールは、変換を完了するためにのみ使用できます。AWS CLI または RDS API を使用するには、[DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更する](#Concepts.MultiAZ.Migrating.Modify) の手順に従います。
**RDS コンソールを使用して、マルチ AZ DB インスタンスのデプロイに変換するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択し、変更する DB インスタンスを選択します。
1. **[Actions]** (アクション) から、**[Convert to Multi-AZ deployment]** (マルチ AZ 配置に変換) を選択します。
1. 変更をすぐに適用するには、確認ページで [**Apply Immediately**] (すぐに適用) を選択します。このオプションを選択してもダウンタイムは発生しませんが、パフォーマンスに影響する可能性があります。または、次のメンテナンスウィンドウの間に更新を適用することもできます。詳細については、「[スケジュール変更設定の使用](USER_ModifyInstance.ApplyImmediately.md)」を参照してください。
1. **[Convert to Multi-AZ]** (マルチ AZ に変換) を選択します。
## DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更する
次の方法で、DB インスタンスをマルチ AZ DB インスタンスのデプロイに変更できます。
+ RDS コンソールを使用して DB インスタンスを変更し、**[Multi-AZ deployment]** (マルチ AZ 配置) を **[Yes]** (はい) に設定します。
+ AWS CLI を使用して [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) コマンドを呼び出し、`--multi-az` オプションを設定します。
+ RDS API を使用して、[ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) オペレーションを呼び出して、`MultiAZ` パラメータを `true` に設定します。
DB インスタンスの変更については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。変更が完了した後、Amazon RDS は、プロセスが完了したことを示すイベント (RDS-EVENT-0025) をトリガーします。Amazon RDS イベントをモニタリングできます。 イベントの詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
# Amazon RDS 用のマルチ AZ DB インスタンスのフェイルオーバー
マルチ AZ DB インスタンスの計画的または計画外の停止がインフラストラクチャの欠陥に起因する場合、Amazon RDS は別のアベイラビリティーゾーンのスタンバイレプリカに自動的に切り替わります。
フェイルオーバーが完了するまでにかかる時間は、プライマリ DB インスタンスが使用できなくなったときのデータベースアクティビティおよびその他の条件によって異なります。フェイルオーバー時間は通常 60～120 秒です。ただし、大規模なトランザクションや長期にわたる復旧プロセスによって、フェイルオーバー時間が増加する場合があります。フェイルオーバーが完了してから、新しいアベイラビリティーゾーンが RDS コンソールに反映されるまでさらに時間がかかる場合があります。
**注記**
マルチ AZ DB インスタンスを再起動するときに手動でフェイルオーバーを強制的に実行することができます。詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
Amazon RDS はフェイルオーバーを自動的に処理するため、管理者が操作しなくても可能な限りすみやかにデータベース操作を再開できます。次の表に記載されている条件のいずれかが発生した場合、プライマリ DB インスタンスがスタンバイレプリカに自動的に切り替わります。これらのフェイルオーバーの理由は、イベントログで確認できます。
| フェイルオーバーした理由 | 説明 |
| --- | --- |
| RDS データベースインスタンスの基盤となるオペレーティングシステムには、オフライン操作でパッチが適用されています。 | OS パッチまたはセキュリティ更新プログラムのメンテナンス期間中に、フェイルオーバーがトリガーされました。 詳細については、「[DB インスタンスのメンテナンス](USER_UpgradeDBInstance.Maintenance.md)」を参照してください。 |
| RDS マルチ AZ インスタンスのプライマリホストが異常です。 | マルチ AZ DB インスタンスのデプロイは、障害のあるプライマリ DB インスタンスを検出し、フェイルオーバーしました。 |
| RDS マルチ AZ インスタンスのプライマリホストで、ネットワーク接続が切断されたため、到達できません。 | RDS モニタリングは、プライマリ DB インスタンスへのネットワーク到達可能性による障害を検出し、フェイルオーバーをトリガーしました。 |
| RDS インスタンスはお客様によって変更されました。 | RDS DB インスタンスの変更により、フェイルオーバーがトリガーされました。 詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。 |
| RDS マルチ AZ プライマリインスタンスはビジーで応答しません。 | プライマリ DB インスタンスが応答しません。次のことを行うことをお勧めします。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.Failover.html) これらの推奨事項の詳細については、[Amazon RDS のモニタリングツール](MonitoringOverview.md) および [Amazon RDS のベストプラクティス](CHAP_BestPractices.md) を参照してください。 |
| RDS マルチ AZ インスタンスのプライマリホストの基盤となるストレージボリュームでエラーが発生しました。 | マルチ AZ DB インスタンスのデプロイは、プライマリ DB インスタンスでストレージの問題を検出し、フェイルオーバーしました。 |
| ユーザーが DB インスタンスのフェイルオーバーをリクエストしました。 | DB インスタンスを再起動し、[**Reboot with failover (フェイルオーバーで再起動)**] を選択しました。 (詳しくは、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。) |
マルチ AZ DB インスタンスがフェイルオーバーされたかどうかを判断するには、次を実行します。
+ フェイルオーバーがスタートされたことを電子メールまたはSMSで通知するようにDBイベントサブスクリプションを設定します。 イベントの詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
+ RDS コンソールまたは API オペレーションを使用して DB イベントを表示します。
+ RDS コンソールまたは API オペレーションを使用して、マルチ AZ DB インスタンスのデプロイの現在の状態を表示します。
フェイルオーバーへの応答、復旧時間の短縮、Amazon RDS のその他のベストプラクティスについては、「[Amazon RDS のベストプラクティス](CHAP_BestPractices.md)」を参照してください。
## DNS 名参照用の JVM TTL の設定
フェイルオーバーメカニズムでは、スタンバイ DB インスタンスをポイントするように DB インスタンスのドメインネームシステム (DNS) レコードが自動的に変更されます。したがって、DB インスタンスへの既存の接続の再確立が必要になります。Java 仮想マシン (JVM) 環境では、Java DNS キャッシュ機構がどのように機能するかによって、JVM 設定の再構成が必要になる場合があります。
JVM は DNS 名参照をキャッシュします。JVM がホスト名を IP アドレスに変換するとき、*time-to-live* (TTL) と呼ばれる指定期間 IP アドレスをキャッシュします。
AWS リソースは、ときどき変更される DNS 名を使用するため、60 秒を超えない TTL 値で JVM を設定することをお勧めします。こうすることにより、リソースの IP アドレスが変更されたときに、アプリケーションは DNS に対して再度クエリを実行することで、リソースの新しい IP アドレスを取得して使用できます。
一部の Java 設定では JVM のデフォルトの TTL が設定されるため、JVM が再起動されるまで、DNS エントリが更新されることはありません。したがって、アプリケーションがまだ実行中に AWS リソースの IP アドレスが変更された場合、JVM を手動で再起動し、キャッシュされた IP 情報が更新されるまで、そのリソースを使用することはできません。この場合、キャッシュされた IP 情報が定期的に更新されるように JVM の TTL を設定することがきわめて重要です。
JVM のデフォルト TTL は、[https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html](https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html) プロパティ値を取得することで取得できます。
```
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
```
**注記**
デフォルト TTL は、JVM のバージョンと、セキュリティマネージャーがインストールされているかどうかに応じて変わります。多くの JVM はデフォルト TTL を 60 秒以下にしています。このような JVM を使用しており、セキュリティマネージャーを使用していない場合、このトピックの残り部分は無視してかまいません。Oracle のセキュリティマネージャーの詳細については、Oracle ドキュメントの 「[The Security Manager](https://docs.oracle.com/javase/tutorial/essential/environment/security.html)」を参照してください。
JVM の TTL を変更するには、`networkaddress.cache.ttl` プロパティ値を設定します。ニーズに応じて、次の方法のいずれかを使用します。
+ JVM を使用するすべてのアプリケーションのプロパティ値をグローバルに設定するには、`networkaddress.cache.ttl` ファイルで `$JAVA_HOME/jre/lib/security/java.security` を設定します。
```
networkaddress.cache.ttl=60
```
+ アプリケーションに対してのみプロパティをローカルに設定するには、ネットワーク接続を確立する前に、アプリケーションの初期化コードで `networkaddress.cache.ttl` を設定します。
```
java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
```
# 追加のストレージボリュームによるマルチ AZ フェイルオーバー
マルチ AZ 配置は、追加のストレージボリュームを持つ DB インスタンスをサポートします。フェイルオーバー中、RDS は DB インスタンスにアタッチされた追加のストレージボリュームを使用して、スタンバイインスタンスに自動的にフェイルオーバーします。このプロセスにより、データ整合性と可用性が確保されます。
追加のストレージボリュームを持つ DB インスタンスのマルチ AZ 配置を設定すると、Amazon RDS はすべてのボリュームを別のアベイラビリティーゾーンのスタンバイインスタンスに自動的にレプリケートします。レプリケートされたストレージには以下が含まれます。
+ プライマリストレージボリューム
+ DB インスタンスにアタッチされたすべての追加のストレージボリューム
フェイルオーバー中、Amazon RDS はスタンバイインスタンスを昇格させ、すべてのストレージボリュームが利用可能で一貫性があることを確認します。フェイルオーバーは、ボリューム名、ストレージタイプ、パフォーマンス特性など、同じストレージ設定を維持します。
フェイルオーバーが成功したら、ストレージ設定の詳細を表示して、すべてのストレージボリュームが正しくアタッチされ、アクセス可能であることを確認します。詳細については、「[DB インスタンスのストレージボリュームの詳細の表示](rds-storage-viewing.md)」を参照してください。
追加のストレージボリュームを持つ DB インスタンスのフェイルオーバー時間は、プライマリストレージのみを持つ DB インスタンスとほぼ同じです。
# Amazon RDS のマルチ AZ DB クラスターデプロイ
ある*マルチ AZ DB クラスターデプロイ*は、2 つの読み取り可能なリードレプリカ DB インスタンスを持つ Amazon RDS の準同期の高可用性のデプロイモードです。マルチ AZ DB クラスターには、同じ AWS リージョン に 3 つの別々のアベイラビリティーゾーンに 1 つのライター DB インスタンスと 2 つのリーダー DB インスタンスがあります。マルチ AZ DB クラスターは、マルチ AZ DB インスタンスの配置と比較して、高可用性、読み取りワークロードの容量の増加、および書き込みレイテンシーの低減を提供します。
[ダウンタイムを短縮して Amazon RDS for MySQL データベースにデータをインポートする](mysql-importing-data-reduced-downtime.md) の説明に従って、オンプレミスデータベースからマルチ AZ DB クラスターにデータをインポートできます。
マルチ AZ DB クラスターのリザーブド DB インスタンスを購入できます。詳細については、「[マルチ AZ DB クラスターのリザーブド DB インスタンス](USER_WorkingWithReservedDBInstances.md#USER_WorkingWithReservedDBInstances.MultiAZDBClusters)」を参照してください。
機能の可用性とサポートは、各データベースエンジンの特定のバージョン、および AWS リージョン によって異なります。マルチ AZ DB クラスターを使用した Amazon RDS のバージョンとリージョンの可用性の詳細ついては、「[Amazon RDS のマルチ AZ DB クラスターでサポートされているリージョンと DB エンジン](Concepts.RDS_Fea_Regions_DB-eng.Feature.MultiAZDBClusters.md)」を参照してください。
**Topics**
+ [マルチ AZ DB クラスターで利用できるインスタンスクラス](#multi-az-db-clusters-concepts.InstanceAvailability)
+ [マルチ AZ DB クラスターアーキテクチャ](#multi-az-db-clusters-concepts-overview)
+ [マルチ AZ DB クラスターのパラメータグループ](#multi-az-db-clusters-concepts-parameter-groups)
+ [マルチ AZ DB クラスターを備えた RDS Proxy](#multi-az-db-clusters-proxy)
+ [レプリカの遅延とマルチ AZ DB クラスター](#multi-az-db-clusters-concepts-replica-lag)
+ [マルチ AZ DB クラスターのスナップショット](#multi-az-db-clusters-concepts-snapshot)
+ [Amazon RDS 用のマルチ AZ DB クラスターの作成](create-multi-az-db-cluster.md)
+ [Amazon RDS のマルチ AZ DB クラスターへの接続](multi-az-db-clusters-concepts-connection-management.md)
+ [AWS コンピューティングリソースと Amazon RDS のマルチ AZ DB クラスターを自動的に接続する](multi-az-compute-rds-connect.md)
+ [Amazon RDS のマルチ AZ DB クラスターの変更](modify-multi-az-db-cluster.md)
+ [Amazon RDS のマルチ AZ DB クラスターのエンジンバージョンのアップグレード](multi-az-db-clusters-upgrading.md)
+ [Amazon RDS のマルチ AZ DB クラスターの名前の変更](multi-az-db-cluster-rename.md)
+ [Amazon RDS のマルチ AZ DB クラスターとリーダー DB インスタンスの再起動](multi-az-db-clusters-concepts-rebooting.md)
+ [Amazon RDS 用のマルチ AZ DB クラスターのフェイルオーバー](multi-az-db-clusters-concepts-failover.md)
+ [Amazon RDS のマルチ AZ DB クラスターを使用した PostgreSQL 論理レプリケーションの設定](USER_MultiAZDBCluster_LogicalRepl.md)
+ [Amazon RDS のマルチ AZ DB クラスターのリードレプリカの操作](USER_MultiAZDBCluster_ReadRepl.md)
+ [Amazon RDS のマルチ AZ DB クラスターからの外部レプリケーションの設定](multi-az-db-clusters-external-replication.md)
+ [Amazon RDS 用のマルチ AZ DB クラスターの削除](USER_DeleteMultiAZDBCluster.Deleting.md)
+ [Amazon RDS のマルチ AZ DB クラスターの制限事項](multi-az-db-clusters-concepts.Limitations.md)
**重要**
マルチ AZ DB クラスターは Aurora DB クラスターと同じではありません。Aurora DB クラスターの情報については、[Amazon Aurora ユーザーガイド](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html)を参照してください。
## マルチ AZ DB クラスターで利用できるインスタンスクラス
マルチ AZ DB クラスター配置は、次の DB インスタンスクラスでサポートされています。`db.m5d`、`db.m6gd`、`db.m6id`、`db.m6idn`、`db.r5d`、`db.r6gd`、`db.x2iedn`、`db.r6id`、`db.r6idn`、`db.c6gd`。
**注記**
`medium` インスタンスサイズをサポートするインスタンスクラスは、c6gd インスタンスクラスのみです。
DB インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
## マルチ AZ DB クラスターアーキテクチャ
マルチ AZ DB クラスターでは、Amazon RDS は DB エンジンのネイティブレプリケーション機能を使用して、ライター DB インスタンスから両方のリーダー DB インスタンスにデータを複製します。ライター DB インスタンスに変更が加えられると、各リーダー DB インスタンスに送信されます。
マルチ AZ DB クラスター配置では、準同期レプリケーションを使用します。変更をコミットするには、少なくとも 1 つのリーダー DB インスタンスからの承認が必要です。イベントが完全に実行され、*すべての*レプリカでコミットされたことを確認する必要はありません。
リーダー DB インスタンスは自動フェイルオーバーターゲットとして機能し、読み取りトラフィックを処理してアプリケーションの読み取りスループットを向上させます。 ライター DB インスタンスで機能停止が発生した場合、RDS はリーダー DB インスタンスのうち 1 つへのフェイルオーバーを管理します。RDS は、最新の変更記録があるリーダー DB インスタンスを基にこれを実行します。
次の図は、マルチ AZ DB クラスターを示しています。
![\[マルチ AZ DB クラスター\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/multi-az-db-cluster.png)
マルチ AZ DB クラスターは、マルチ AZ DB インスタンスの配置と比較して、通常、書き込みレイテンシーが少なくなります。また、リーダー DB インスタンスで読み取り専用ワークロードを実行することもできます。RDS コンソールには、ライター DB インスタンスのアベイラビリティーゾーンとリーダー DB インスタンスのアベイラビリティーゾーンが表示されます。また、 [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)CLI コマンドまたはこの情報を見つけるための[DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html)API オペレーションを使用することもできます。
**重要**
RDS for MySQL マルチ AZ DB クラスターのレプリケーションエラーを防ぐため、すべてのテーブルにプライマリキーを設定することを強くお勧めします。
## マルチ AZ DB クラスターのパラメータグループ
マルチ AZ DBクラスターでは、*DB クラスターパラメータグループ*は、マルチ AZ DB クラスター内のすべての DB インスタンスに適用されるエンジン構成値のコンテナーとして機能します。
マルチ AZ DB クラスターでは、*DB パラメータグループ*は、DB エンジンおよび DB エンジンバージョンのデフォルトの DB パラメータグループに設定されています。DB クラスターパラメータグループの設定は、クラスター内のすべての DB インスタンスに使用されます。
パラメータグループの詳細については、「[マルチ AZ DB クラスターの DB クラスターパラメータグループを使用する](USER_WorkingWithDBClusterParamGroups.md)」を参照してください。
## マルチ AZ DB クラスターを備えた RDS Proxy
Amazon RDS Proxy を使用すると、マルチ AZ DB クラスターに対してプロキシを作成できます。RDS プロキシを使用すると、アプリケーションではデータベース接続をプールおよび共有し、そのスケール能力を向上させることができます。各プロキシは、接続の*多重化*も実行します。これは接続の再利用とも呼ばれます。多重化により、RDS Proxy は 1 つの基となるデータベース接続を使用して 1 つのトランザクションのすべてのオペレーションを実行します。RDS Proxy を使用すると、マルチ AZ DB クラスターのマイナーバージョンアップグレードのダウンタイムを 1 秒以下に短縮することもできます。RDS Prox のメリットの詳細については、「[Amazon RDS Proxy ](rds-proxy.md)」を参照してください。
マルチ AZ DB クラスターのプロキシを設定するには、クラスター作成時に **[RDS Proxy の作成]** を選択します。RDS Proxy エンドポイントの作成と管理の手順については、「[Amazon RDS Proxy エンドポイントの操作](rds-proxy-endpoints.md)」を参照してください。
## レプリカの遅延とマルチ AZ DB クラスター
*レプリカの遅延*とは、ライター DB インスタンスの最新のトランザクションと、リーダー DB インスタンスで最後に適用されたトランザクションとの時間の差です。Amazon CloudWatch メトリクス `ReplicaLag` は、この時間の差を表します。CloudWatch のメトリクスの詳細については、「[Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。
マルチ AZ DB クラスターでは高い書き込みパフォーマンスが得られますが、エンジンベースのレプリケーションの性質上、レプリカの遅延が発生する可能性があります。フェイルオーバーでは、新しいライター DB インスタンスに昇格する前にまずレプリカの遅延を解決する必要があるため、レプリカの遅延のモニタリングおよび管理は考慮事項です。
RDS for MySQL マルチ AZ DB クラスターの場合、フェイルオーバーの時間は残りの両方のリーダー DB インスタンスのレプリカの遅延によって異なります。どちらのリーダー DB インスタンスについても、いずれかが新しいライター DB インスタンスに昇格する前に、未適用のトランザクションを適用する必要があります。
RDS for PostgreSQL マルチ AZ DB クラスターの場合、フェイルオーバーの時間は残りの 2 つのリーダー DB インスタンスの最も低いレプリカの遅延によって異なります。レプリカの遅延が最も低いリーダー DB インスタンスについては、新しいライター DB インスタンスに昇格する前に、未適用のトランザクションを適用する必要があります。
レプリカの遅延が設定された時間を超過した際に CloudWatch アラームを作成する方法のチュートリアルについては、「[チュートリアル: Amazon RDS のマルチ AZ DB クラスターレプリカラグ用の Amazon CloudWatch アラームを作成する](multi-az-db-cluster-cloudwatch-alarm.md)」を参照してください。
### レプリカの遅延の一般的な原因
一般に、レプリカの遅延は書き込みワークロードが高すぎてリーダー DB インスタンスでトランザクションを効率的に適用できない場合に発生します。異なるワークロードでは、一時的に、または継続的にレプリカの遅延が発生する可能性があります。一般的な原因の例をいくつか次に示します。
+ 書き込みの同時実行性が高いか、ライター DB インスタンスで大量のバッチ更新が行われるため、リーダー DB インスタンスの適用プロセスが遅れている。
+ 1 つ以上のリーダー DB インスタンスでリソースを使用しており、読み取りワークロード負荷が高い。低速または大規模なクエリを実行すると、適用プロセスに影響し、レプリカの遅延が発生する可能性があります。
+ 大量のデータまたは DDL ステートメントを変更するトランザクション。データベースのコミットの順序を保持する必要があるため、レプリカの遅延が一時的に増加することがあります。
### レプリカの遅延の軽減
RDS for MySQL および RDS for PostgreSQL のマルチ AZ DB クラスターでは、ライター DB インスタンスの負荷を軽減することで、レプリカの遅延を軽減できます。また、フロー制御を使用してレプリカの遅延を軽減できます。*フロー制御*は、ライター DB インスタンスに対する書き込みをスロットリングすることで機能します。これにより、レプリカの遅延が無制限に増加し続けることを防ぎます。書き込みスロットリングは、トランザクションの最後に遅延を追加することで実現されます。これにより、ライター DB インスタンスの書き込みスループットが低下します。フロー制御は遅延をなくすことを保証するものではありませんが、多くのワークロードで全体的な遅延を軽減するのに役立ちます。次のセクションでは、RDS for MySQL および RDS for PostgreSQL でのフロー制御の使用方法について説明します。
#### RDS for MySQL でのフロー制御によるレプリカの遅延の軽減
RDS for MySQL マルチ AZ DB クラスターを使用している場合、動的パラメータ `rpl_semi_sync_master_target_apply_lag` を使用することでデフォルトでフロー制御が有効になります。このパラメータは、レプリカの遅延における上限を指定します。レプリカの遅延が設定された上限に近づくと、フロー制御は指定された値より小さいレプリカの遅延を含むようにライター DB インスタンス上の書き込みトランザクションをスロットリングします。場合によっては、レプリカの遅延が指定された上限を超えることがあります。デフォルトでは、パラメータは 120 秒に設定されています。フロー制御を無効にするには、このパラメータを最大値の 86,400 秒 (1 日) に設定します。
フロー制御によって挿入される現在の遅延を表示するには、次のクエリを実行してパラメータ `Rpl_semi_sync_master_flow_control_current_delay` を表示します。
```
SHOW GLOBAL STATUS like '%flow_control%';
```
出力は以下のようになります。
```
+-------------------------------------------------+-------+
| Variable_name | Value |
+-------------------------------------------------+-------+
| Rpl_semi_sync_master_flow_control_current_delay | 2010 |
+-------------------------------------------------+-------+
1 row in set (0.00 sec)
```
**注記**
遅延はマイクロ秒単位で示されます。
RDS for MySQL マルチ AZ DB クラスターの Performance Insights を有効にすると、クエリがフロー制御によって遅延したことを示す SQL ステートメントに対応する待機イベントをモニタリングできます。フロー制御により遅延が発生すると、Performance Insights ダッシュボードで SQL ステートメントに対応する待機イベント `/wait/synch/cond/semisync/semi_sync_flow_control_delay_cond` を表示できます。これらのメトリクスを表示するには、Performance Schema が有効になっていることを確認してください。Performance Insights の詳細については、「[Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング](USER_PerfInsights.md)」を参照してください。
#### RDS for PostgreSQL でのフロー制御によるレプリカの遅延の軽減
RDS for PostgreSQL のマルチ AZ DB クラスターを使用している場合、フロー制御は拡張機能としてデプロイされています。これにより、DB クラスターのすべての DB インスタンスでバックグラウンドワーカーが開始します。デフォルトでは、リーダー DB インスタンスのバックグラウンドワーカーは、現在のレプリカの遅延をライター DB インスタンスのバックグラウンドワーカーに伝えます。いずれかのリーダー DB インスタンスで遅延が 2 分を超える場合、ライター DB インスタンスのバックグラウンドワーカーは、トランザクションの最後に遅延を追加します。遅延のしきい値を制御するには、パラメータ `flow_control.target_standby_apply_lag` を使用します。
フロー制御が PostgreSQL プロセスをスロットリングすると、`pg_stat_activity` および Performance Insights の `Extension` 待機イベントに表示されます。現在追加されている遅延の量に関する詳細が関数 `get_flow_control_stats` に表示されます。
フロー制御は、短いが負荷の高い同時トランザクションを持つほとんどのオンライントランザクション処理 (OLTP) のワークロードにメリットがあります。バッチ操作などの長時間実行されるトランザクションによって遅延が発生した場合、それほど大きなメリットはありません。
フロー制御を無効にするには、`shared_preload_libraries` から拡張機能を削除するか、DB インスタンスを再起動します。
## マルチ AZ DB クラスターのスナップショット
Amazon RDS は、設定されたバックアップ期間中に、マルチ AZ DB クラスターの自動バックアップを作成して保存します。RDS は DB クラスターのストレージボリュームのスナップショットを作成し、個々のインスタンスだけではなく、クラスター全体をバックアップします。
マルチ AZ DB クラスターの手動バックアップを取ることもできます。非常に長期間のバックアップの場合、スナップショットデータを Amazon S3 にエクスポートすることを検討してください。詳細については、「[Amazon RDS のマルチ AZ DB クラスターのスナップショットの作成](USER_CreateMultiAZDBClusterSnapshot.md)」を参照してください。
マルチ AZ DB クラスターを指定の時点に復元し、新しいマルチ AZ DB クラスターを作成できます。手順については、「[マルチ AZ DB クラスターを指定の時点の状態に復元する](USER_PIT.MultiAZDBCluster.md)」を参照してください。
または、マルチ AZ DB クラスターのスナップショットをシングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイに復元することができます。手順については、「[マルチ AZ DB クラスターのスナップショットから DB インスタンスへの復元](USER_RestoreFromMultiAZDBClusterSnapshot.md)」を参照してください。
# Amazon RDS 用のマルチ AZ DB クラスターの作成
マルチ AZ DB クラスターには、3 つの別々のアベイラビリティーゾーンに 1 つのライター DB インスタンスと 2 つのリーダー DB インスタンスがあります。マルチ AZ DB クラスターは、マルチ AZ 配置と比較して、高可用性、読み取りワークロードの容量の増加、および低レイテンシーを提供します。マルチ AZ DB の配置の詳細については、「[Amazon RDS のマルチ AZ DB クラスターデプロイ](multi-az-db-clusters-concepts.md)」を参照してください。
**注記**
マルチ AZ DB クラスターは MySQL および PostgreSQL DB エンジンでのみサポートされます。
## DB クラスターの前提条件
**重要**
マルチ AZ DB クラスターを作成する前に、[Amazon RDS 環境のセットアップ](CHAP_SettingUp.md) のタスクを完了する必要があります。
マルチ AZ DB クラスターを作成する前に完了しておく必要がある前提条件を次に示します。
**Topics**
+ [DB クラスターのネットワークを設定する](#create-multi-az-db-cluster-prerequisites-VPC)
+ [追加の前提条件](#create-multi-az-db-cluster-prerequisites-additional)
### DB クラスターのネットワークを設定する
マルチ AZ DB クラスターは、Amazon VPC サービスに基づく仮想プライベートクラウド (VPC) でのみ作成できます。少なくとも 3 つのアベイラビリティーゾーンを持つ AWS リージョン である必要があります。DB クラスターで選択する DB サブネットグループは、少なくとも 3 つのアベイラビリティーゾーンを対象とする必要があります。この設定により、DB クラスターの各 DB インスタンスが別のアベイラビリティーゾーンに配置されます。
新しい DB クラスターと同じ VPC 内の Amazon EC2 インスタンス間の接続を設定するには、DB クラスターの作成時に設定します。同じ VPC 内の EC2 インスタンス以外のリソースから DB クラスターに接続するには、ネットワーク接続を手動で設定します。
**Topics**
+ [EC2 インスタンスとの自動ネットワーク接続を設定する](#create-multi-az-db-cluster-prerequisites-VPC-automatic)
+ [ネットワークを手動で設定する](#create-multi-az-db-cluster-prerequisites-VPC-manual)
#### EC2 インスタンスとの自動ネットワーク接続を設定する
マルチ AZ DB クラスターを作成する場合は、AWS マネジメントコンソール を使用して EC2 インスタンスと新しい DB クラスター間の接続をセットアップできます。これを行うと、RDS では VPC とネットワークの設定を自動で行います。EC2 インスタンスが DB クラスターにアクセスできるように、EC2 インスタンスと同じ VPC 内に DB クラスターを作成します。
EC2 インスタンスと DB クラスターを接続するための要件は次のとおりです。
+ DB クラスターを作成する前に、AWS リージョン に EC2 インスタンスが存在する必要があります。
AWS リージョン に EC2 インスタンスが存在しない場合、コンソールには EC2 インスタンス作成用のリンクが表示されます。
+ DB クラスターを作成するユーザーには、次の操作を実行する権限が必要です。
+ `ec2:AssociateRouteTable`
+ `ec2:AuthorizeSecurityGroupEgress`
+ `ec2:AuthorizeSecurityGroupIngress`
+ `ec2:CreateRouteTable`
+ `ec2:CreateSubnet`
+ `ec2:CreateSecurityGroup`
+ `ec2:DescribeInstances`
+ `ec2:DescribeNetworkInterfaces`
+ `ec2:DescribeRouteTables`
+ `ec2:DescribeSecurityGroups`
+ `ec2:DescribeSubnets`
+ `ec2:ModifyNetworkInterfaceAttribute`
+ `ec2:RevokeSecurityGroupEgress`
このオプションを使用すると、プライベート DB クラスターが作成されます。DB クラスターでは、プライベートサブネットのみを持つ DB サブネットグループを使用して、VPC 内のリソースへのアクセスを制限します。
EC2 インスタンスを DB クラスターに接続するには、**[Create database]** (データベースの作成) ページの **[Connectivity]** (接続) セクションで、**[Connect to an EC2 compute resource]** (EC2 コンピューティングリソースに接続する) を選択します。
![\[EC2 インスタンスに接続する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ec2-set-up-connection-create.png)
**[Connect to an EC2 compute resource]** (EC2 コンピューティングリソースに接続する) を選択すると、RDS では次のオプションを自動的に設定します。**[Don't connect to an EC2 compute resource]** (EC2 コンピューティングリソースに接続しない) を選択して EC2 インスタンスとの接続をセットアップしない限り、これらの設定は変更できません。
****
| コンソールオプション | 自動ログ記録 |
| --- | --- |
| **仮想プライベートクラウド (VPC)**。 | RDS は EC2 インスタンスに関連付けられている VPC に設定します。 |
| **DB サブネットグループ** | RDS では、EC2 インスタンスと同じアベイラビリティーゾーンにプライベートサブネットを持つ DB サブネットグループが必要です。この要件を満たす DB サブネットグループが存在する場合、RDS は既存の DB サブネットグループを使用します。デフォルトでは、このオプションは [Automatic setup] (自動セットアップ) に設定されています。**[Automatic setup]** (自動セットアップ) を選択したとき、この要件を満たす DB サブネットグループがない場合、次のアクションが実行されます。RDS は 3 つのアベイラビリティーゾーンで 3 つの使用可能なプライベートサブネットを使用します。アベイラビリティーゾーンのうちの 1 つは EC2 インスタンスと同じです。プライベートサブネットがアベイラビリティーゾーンで使用できない場合、RDS はアベイラビリティーゾーンにプライベートサブネットを作成します。次に、RDS は DB サブネットグループを作成します。プライベートサブネットが使用可能な場合、RDS はサブネットに関連付けられているルートテーブルを使用して、作成したサブネットをこのルートテーブルに追加します。プライベートサブネットが使用できない場合、RDS はインターネットゲートウェイにアクセスできないルートテーブルを作成し、作成したサブネットをルートテーブルに追加します。RDS では、既存の DB サブネットグループを使用することもできます。既存の DB サブネットグループを使用する場合は、**[Choose existing]** (既存を選択) を選択します。 |
| **パブリックアクセス** | RDS では **[No]** (いいえ) を選択して、DB クラスターがパブリックアクセス可能にならないようにします。 セキュリティ上の理由から、データベースは非公開として、インターネットからアクセスできないようにするのがベストプラクティスです。 |
| **VPC セキュリティグループ (ファイアウォール)** | RDS では DB クラスターに関連付けられている新しいセキュリティグループを作成します。セキュリティグループの名前は `rds-ec2-n` で、`n` は数字です。このセキュリティグループには、EC2 VPC セキュリティグループ (ファイアウォール) をソースとするインバウンドルールが含まれています。DB クラスターに関連付けられているこのセキュリティグループにより、EC2 インスタンスが DB クラスターにアクセスできます。 また、RDS では EC2 インスタンス関連付けられている新しいセキュリティグループを作成します。セキュリティグループの名前は `ec2-rds-n` で、`n` は数字です。このセキュリティグループには、DB クラスターの VPC セキュリティグループをソースとするアウトバウンドルールが含まれています。このセキュリティグループにより、EC2 インスタンスは DB クラスターにトラフィックを送信できます。 **[Create new]** (新規作成) を選択して、新しいセキュリティグループの名前を入力すると、別のセキュリティグループを新規に追加できます。 既存のセキュリティグループを追加するには、**[Choose existing]** (既存を選択) を選択し、追加するセキュリティグループを選択します。 |
| **アベイラビリティーゾーン (AZ** | RDS では、マルチ AZ DB クラスター配置内の 1 つの DB インスタンスの EC2 インスタンスのアベイラビリティーゾーンを選択します。RDS は他の両方の DB インスタンスに対して異なるアベイラビリティーゾーンをランダムに選択します。書き込み DB インスタンスは、EC2 インスタンスと同じアベイラビリティーゾーンに作成されます。フェイルオーバーと書き込み DB インスタンスが異なるアベイラビリティーゾーンにある場合、アベイラビリティーゾーン間のコストが発生する可能性があります。 |
これらの設定の詳細については、「[マルチ AZ DB クラスターを作成するための設定](#create-multi-az-db-cluster-settings)」をご参照ください。
DB クラスターの作成後にこれらの設定を変更すると、EC2 インスタンスと DB クラスター間の接続に影響する可能性があります。
#### ネットワークを手動で設定する
同じ VPC 内の EC2 インスタンス以外のリソースから DB クラスターに接続するには、ネットワーク接続を手動で設定します。AWS マネジメントコンソール を使用して マルチ AZ DB クラスターを作成する場合は、お客様に代わって Amazon RDS に VPC を自動的に作成させることができます。または、既存の VPC を使うか、 マルチ AZ DB クラスター用に新しい VPC を作成することができます。マルチ AZ DB クラスターで使用するには、VPC の少なくとも 3 つのアベイラビリティーゾーンのそれぞれに少なくとも 1 つのサブネットが必要です。VPC の詳細については、「[Amazon VPC と Amazon RDS](USER_VPC.md)」を参照してください。
デフォルト VPC を持っていない、または VPC を作成しておらず、コンソールを使用する予定がない場合は、次の操作を実行します。
+ DB クラスターをデプロイする AWSリージョンで、少なくとも 3 つのアベイラビリティーゾーンのそれぞれに 1 つ以上のサブネットを持つ VPC を作成します。(詳しくは、「[VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md#Overview.RDSVPC.Create)」を参照してください。)
+ DB クラスターへの接続を許可する VPC セキュリティグループを指定します。詳細については、「[セキュリティグループを作成して VPC 内の DB インスタンスへのアクセスを提供する](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup)」および「[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md)」を参照してください。
+ マルチAZ DB クラスターが使用できる VPC 内の最低 3つのサブネットを定義する RDS DBサブネットグループを指定します。(詳しくは、「[DB サブネットグループの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Subnets)」を参照してください。)
マルチ AZ DB クラスターに適用される制限事項については、「[Amazon RDS のマルチ AZ DB クラスターの制限事項](multi-az-db-clusters-concepts.Limitations.md)」を参照してください。
マルチ AZ DB クラスターと同じ VPC にないリソースに接続する場合は、[VPC の DB インスタンスにアクセスするシナリオ](USER_VPC.Scenarios.md) の該当するシナリオを参照してください。
### 追加の前提条件
マルチ AZ DB クラスターを作成する前に、以下に示す追加の前提条件を検討してください。
+ DB クラスターの設定パラメータを調整するには、必要なパラメータ設定を持つ DB クラスターパラメータグループを指定します。DB クラスターのパラメータグループの作成または変更については、「[マルチ AZ DB クラスターのパラメータグループ](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups) 」を参照してください。
+ DB クラスター用に指定する TCP/IP ポート番号を確認します。一部の会社のファイアウォールによっては、デフォルトポートへの接続がブロックされます。会社のファイアウォールがデフォルトのポートをブロックする場合は、お客様の DB クラスター用に別のポートを選択します。DB クラスターのすべての DB インスタンスは同じポートを使用します。
+ データベースのメジャーエンジンバージョンが RDS 標準サポート終了日に達した場合は、延長サポート CLI オプションまたは RDS API パラメータを使用する必要があります。詳細については、「[マルチ AZ DB クラスターを作成するための設定](#create-multi-az-db-cluster-settings)」の「RDS 延長サポート」を参照してください。
## DB クラスターの作成
マルチAZ DB クラスターは、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して作成できます。
### コンソール
マルチAZ DB クラスターを作成するには、**[Availability and durability]** (可用性と耐久性) セクションで**[Multi-AZ DB cluster]** (マルチAZ DB クラスター) を選択します。
**コンソールを使用して マルチAZ DB クラスターを作成します**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. AWS マネジメントコンソール の右上で、DB クラスターを作成する AWS リージョン を選択します。
マルチ AZ DB クラスターをサポートする AWS リージョン の詳細ついては、「[Amazon RDS のマルチ AZ DB クラスターの制限事項](multi-az-db-clusters-concepts.Limitations.md)」を参照してください。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. **[データベースの作成]** を選択します。
マルチ AZ DB クラスターを作成するには、**スタンダード作成**が選択され、**イージークリエイト**ではないことを確認します。
1. **エンジンのタイプ**で、**MySQL**または**PostgreSQL**を選択します。
1. 「**バージョン**」 で、DB のエンジンバージョンを選択します。
マルチ AZ DB クラスターをサポートする DB エンジンバージョンの詳細ついては、「[Amazon RDS のマルチ AZ DB クラスターの制限事項](multi-az-db-clusters-concepts.Limitations.md)」を参照してください。
1. **テンプレート**で、デプロイに適したテンプレートを選択します。
1. **[Availability and durability]** (可用性と耐久性) で、**[Multi-AZ DB cluster]** (マルチ AZ DB クラスター)-選択します。
![\[マルチ AZ DB クラスターの選択\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/multi-az-db-cluster-create.png)
1. **[DB cluster identifier]** (DB クラスター識別子)で、DB クラスターの識別子を入力します。
1. **マスターユーザーネーム**で、マスターユーザーネームを入力するか、デフォルトの設定のままにします。
1. マスターパスワードを入力します。
1. [**設定**] セクションで、[**認証情報の設定**] を開きます。
1. パスワードを指定する場合は、「**パスワードの自動生成**」ボックスが選択されている場合はオフにします。
1. (オプション) **マスターユーザーネーム**の値を変更します。
1. **マスターパスワード**と**確認パスワード**に同じパスワードを入力します。
1. **[DB インスタンスクラス]** で、DB インスタンスクラスを選択します。サポートされているインスタンスクラスのリストについては、「[マルチ AZ DB クラスターで利用できるインスタンスクラス](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts.InstanceAvailability)」を参照してください。
1. (オプション) この DB クラスターのコンピューティングリソースへの接続を設定します。
DB クラスターの作成時に、Amazon EC2 インスタンスと新しい DB クラスター間の接続を設定できます。詳細については、「[EC2 インスタンスとの自動ネットワーク接続を設定する](#create-multi-az-db-cluster-prerequisites-VPC-automatic)」を参照してください。
1. **[VPC セキュリティグループ (ファイアウォール)]** の **[接続]** セクションで **[新規作成]** を選択した場合、ローカルコンピュータの IP アドレスにデータベースへのアクセスを許可するインバウンドルールを使用して VPC セキュリティグループが作成されます。
1. 残りのセクションで、DB クラスター設定を指定します。各設定の詳細については、「[マルチ AZ DB クラスターを作成するための設定](#create-multi-az-db-cluster-settings)」を参照してください。
1. [**データベースの作成**] を選択します。
自動生成されたパスワードを使用することを選択した場合は、[**データベース**] ページに [**認証情報の詳細の表示**] ボタンが表示されます。
DB クラスターのマスターユーザー名およびパスワードを表示するには、[**認証情報の詳細の表示**] を選択します。
マスターユーザーとして DB クラスターに接続するには、表示されているユーザー名およびパスワードを使用します。
**重要**
マスターユーザーのパスワードを再度表示することはできません。
1. 「**データベース**」 で、新しい DB クラスターの名前を選択します。
RDS コンソールに、新しい DB クラスターの詳細が表示されます。DB クラスターが作成され、使用できるようになるまで、DB クラスターのステータスは 「**作成中**」 になります。ステータスが **[Available]** (使用可能) に変わると、DB クラスターに接続できます。DB クラスタークラスと割り当てられたストレージによっては、新しい DB クラスターを使用できるようになるまで数分かかる可能性があります。
### AWS CLI
「AWS CLI」を使用してマルチ AZ DB クラスターを作成する前に、必要な前提条件を満たすことを確認してください。これには、VPC と RDS DB サブネットグループの作成が含まれます。(詳しくは、「[DB クラスターの前提条件](#create-multi-az-db-cluster-prerequisites)」を参照してください。)
「AWS CLI」を使用してマルチ AZ DB クラスターを作成するには、[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)コマンドを呼び出します。「`--db-cluster-identifier`」を指定します。向けの「`--engine`」オプションで、`mysql`または`postgres`のいずれかを指定します。
各オプションの詳細については、「」を参照してください。[マルチ AZ DB クラスターを作成するための設定](#create-multi-az-db-cluster-settings)
マルチ AZ DB クラスターをサポートする AWS リージョン、DB エンジン、および DB エンジンバージョンの詳細ついては、「[Amazon RDS のマルチ AZ DB クラスターの制限事項](multi-az-db-clusters-concepts.Limitations.md)」を参照してください。
`create-db-cluster`コマンドは、DB クラスターのライター DB インスタンスと 2 つのリーダー DB インスタンスを作成します。各 DB インスタンスが異なるアベイラビリティーゾーンにあります。
例えば、次のコマンドは `mysql-multi-az-db-cluster`という名前のMySQL 8.0 マルチ AZ DB クラスターを作成します。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds create-db-cluster \
2. --db-cluster-identifier mysql-multi-az-db-cluster \
3. --engine mysql \
4. --engine-version 8.0.32 \
5. --master-username admin \
6. --manage-master-user-password \
7. --port 3306 \
8. --backup-retention-period 1 \
9. --db-subnet-group-name default \
10. --allocated-storage 4000 \
11. --storage-type io1 \
12. --iops 10000 \
13. --db-cluster-instance-class db.m5d.xlarge
```
Windows の場合:
```
1. aws rds create-db-cluster ^
2. --db-cluster-identifier mysql-multi-az-db-cluster ^
3. --engine mysql ^
4. --engine-version 8.0.32 ^
5. --manage-master-user-password ^
6. --master-username admin ^
7. --port 3306 ^
8. --backup-retention-period 1 ^
9. --db-subnet-group-name default ^
10. --allocated-storage 4000 ^
11. --storage-type io1 ^
12. --iops 10000 ^
13. --db-cluster-instance-class db.m5d.xlarge
```
次のコマンドは`postgresql-multi-az-db-cluster`という名前の PostgreSQL 13.4 マルチ AZ DB クラスターを作成します。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds create-db-cluster \
2. --db-cluster-identifier postgresql-multi-az-db-cluster \
3. --engine postgres \
4. --engine-version 13.4 \
5. --manage-master-user-password \
6. --master-username postgres \
7. --port 5432 \
8. --backup-retention-period 1 \
9. --db-subnet-group-name default \
10. --allocated-storage 4000 \
11. --storage-type io1 \
12. --iops 10000 \
13. --db-cluster-instance-class db.m5d.xlarge
```
Windows の場合:
```
1. aws rds create-db-cluster ^
2. --db-cluster-identifier postgresql-multi-az-db-cluster ^
3. --engine postgres ^
4. --engine-version 13.4 ^
5. --manage-master-user-password ^
6. --master-username postgres ^
7. --port 5432 ^
8. --backup-retention-period 1 ^
9. --db-subnet-group-name default ^
10. --allocated-storage 4000 ^
11. --storage-type io1 ^
12. --iops 10000 ^
13. --db-cluster-instance-class db.m5d.xlarge
```
### RDS API
RDS API を使用してマルチ AZ DB クラスターを作成する前に、VPC や RDS DB サブネットグループの作成など、必要な前提条件を満たすことを確認してください。(詳しくは、「[DB クラスターの前提条件](#create-multi-az-db-cluster-prerequisites)」を参照してください。)
RDS API を使用してマルチマスタークラスターを作成するには、[CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) オペレーションを実行します。「`DBClusterIdentifier`」 を指定します。`Engine`パラメータは、`mysql`または`postgresql`のいずれかを指定します。
各オプションの詳細については、「」を参照してください。[マルチ AZ DB クラスターを作成するための設定](#create-multi-az-db-cluster-settings)
`CreateDBCluster`オペレーションは、DB クラスターのライター DB インスタンスと2つのリーダー DB インスタンスを作成します。各 DB インスタンスが異なるアベイラビリティーゾーンにあります。
## マルチ AZ DB クラスターを作成するための設定
マルチ AZ DB クラスターを作成するときに選択する設定の詳細については、次の表を参照してください。AWS CLIのオプションの詳細については、[create-db-clusterを](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)参照してください。RDS API パラメータの詳細については、「[CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html)」を参照してください。
| コンソール設定 | 設定の説明 | CLI オプションと RDS API パラメータ |
| --- | --- | --- |
| **ストレージ割り当て** | DB クラスター内の各 DB インスタンスに割り当てるストレージの量 (ギビバイト単位)。(詳しくは、「[Amazon RDS DB インスタンスストレージ](CHAP_Storage.md)」を参照してください。) | **CLI オプション:** `--allocated-storage` **API パラメータ:** `AllocatedStorage` |
| マイナーバージョン自動アップグレード | **自動マイナーバージョンアップグレード**を有効にして、DB クラスターが優先マイナー DB エンジンバージョンアップグレードを利用可能になったときに自動的に受信するようにします。Amazon RDS では、メンテナンスウィンドウでマイナーバージョンの自動アップグレードが実行されます。 | **CLI オプション:** `--auto-minor-version-upgrade` `--no-auto-minor-version-upgrade` **API パラメータ:** `AutoMinorVersionUpgrade` |
| バックアップの保存期間 | DB クラスターの自動バックアップを保持する日数。マルチ AZ DB クラスターの場合、この値は**1**以上に設定する必要があります。 (詳しくは、「[バックアップの概要](USER_WorkingWithAutomatedBackups.md)」を参照してください。) | **CLI オプション:** `--backup-retention-period` **API パラメータ:** `BackupRetentionPeriod` |
| バックアップ期間: | Amazon RDS が DB クラスターのバックアップを自動的に作成する期間。データベースのバックアップを保持する期間を指定しない場合は、デフォルトの「**指定なし**」 を使用します。 詳細については、「[バックアップの概要](USER_WorkingWithAutomatedBackups.md)」を参照してください。 | **CLI オプション:** `--preferred-backup-window` **API パラメータ:** `PreferredBackupWindow` |
| **認証局** | DB クラスターによって使用されるサーバー証明書の認定機関 (CA)。 詳細については、「[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md)」を参照してください。 | **CLI オプション:** `--ca-certificate-identifier` **RDS API パラメータ:** `CACertificateIdentifier` |
| Copy tags to snapshots | このオプションは、DB スナップショットの作成時に、DB クラスターの任意のタグを、そのスナップショットにコピーします。 (詳しくは、「[ Amazon RDS リソースのタグ付け](USER_Tagging.md)」を参照してください。) | **CLI オプション:** `-copy-tags-to-snapshot` `-no-copy-tags-to-snapshot` **RDS API パラメータ:** `CopyTagsToSnapshot` |
| データベース認証 | 使用するデータベース認証オプション。 データベースパスワードのみを使用してデータベースのユーザーを認証するには、[**パスワード認証**] を選択します。 ユーザーとロールでデータベースパスワードとユーザー認証情報を使用してデータベースユーザーを認証するには、**[Password and IAM DB authentication]** (パスワードと IAM DB 認証) を選択します。詳細については、「[MariaDB、MySQL、および PostgreSQL の IAM データベース認証](UsingWithRDS.IAMDBAuth.md)」を参照してください。 | **CLI オプション:** `--enable-iam-database-authentication` `--no-enable-iam-database-authentication` **RDS API パラメータ:** `EnableIAMDatabaseAuthentication` |
| データベースポート | DB クラスターへのアクセスに使用するポート。デフォルトのポートが示されています。 DB クラスターの作成後にポートを変更することはできません。 一部の会社のファイアウォールは、これらのデフォルトポートへの接続をブロックします。会社のファイアウォールがデフォルトのポートをブロックする場合は、お客様の DB クラスター用に別のポートを選択します。 | **CLI オプション:** `--port` **RDS API パラメータ:** `Port` |
| DB クラスター識別子 | DB クラスターの名前。オンプレミスのサーバーに名前を付けるのと同様に、DB クラスターに名前を付けます。DB クラスター識別子は、英数字 63 文字まで含めることができ、選択した AWS リージョン内で自分のアカウントに対して一意であることが必要です。 | **CLI オプション:** `--db-cluster-identifier` **RDS API パラメータ:** `DBClusterIdentifier` |
| DB インスタンスクラス: | マルチ AZ DB クラスター内の各 DB インスタンス (`db.m5d.xlarge`など) の計算容量とメモリ容量。 可能であれば、一般的なクエリの作業セットをメモリに保持できる十分な大きさの DB インスタンスクラスを選択します。作業セットがメモリに保持されていると、システムによるディスクへの書き込みが回避され、これによりパフォーマンスが向上します。 サポートされているインスタンスクラスのリストについては、「[マルチ AZ DB クラスターで利用できるインスタンスクラス](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts.InstanceAvailability)」を参照してください。 | **CLI オプション:** `--db-cluster-instance-class` **RDS API パラメータ:** `DBClusterInstanceClass` |
| **DB クラスターのパラメータグループ** | DB クラスターに関連付ける DB クラスターのパラメータグループ。 (詳しくは、「[マルチ AZ DB クラスターのパラメータグループ](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups)」を参照してください。) | **CLI オプション:** `--db-cluster-parameter-group-name` **RDS API パラメータ:** `DBClusterParameterGroupName` |
| DB エンジンバージョン | 使用するデータベースエンジンのバージョン。 | **CLI オプション:** `--engine-version` **RDS API パラメータ:** `EngineVersion` |
| DB クラスターのパラメータグループ | DB クラスターに関連付けられている DB インスタンスパラメータグループ。 詳細については、「[マルチ AZ DB クラスターのパラメータグループ](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups)」を参照してください。 | **CLI オプション:** `--db-cluster-parameter-group-name` **RDS API パラメータ:** `DBClusterParameterGroupName` |
| DB サブネットグループ: | DB クラスターで使用する DB サブネットグループ。既存の DB サブネットグループを使用するには、[Choose existing] (既存を選択) を選択します。次に、[Existing DB subnet groups] (既存の DB サブネットグループ) ドロップダウンリストから必要なサブネットグループを選択します。RDS が互換性のある DB サブネットグループを選択できるようにするには、**[Automatic setup]** (自動セットアップ) を選択します。存在しない場合、RDS はクラスターの新しいサブネットグループを作成します。詳細については、「[DB サブネットグループの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Subnets)」を参照してください。 | **CLI オプション:** `--db-subnet-group-name` **RDS API パラメータ:** `DBSubnetGroupName` |
| 削除保護 | **削除保護を有効**にして、DB クラスターが削除されないようにします。コンソールを使用して本番 DB クラスターを作成する場合、削除保護はデフォルトでオンになっています。 (詳しくは、「[DB インスタンスを削除する](USER_DeleteInstance.md)」を参照してください。) | **CLI オプション:** `--deletion-protection` `--no-deletion-protection` **RDS API パラメータ:** `DeletionProtection` |
| 暗号化 | この DB クラスターを保管時に暗号化するには、「**Enable Encryption**」 を選択します。 マルチ AZ DB クラスターでは、暗号化がデフォルトでオンになっています。 (詳しくは、「[Amazon RDS リソースの暗号化](Overview.Encryption.md)」を参照してください。) | **CLI オプション:** `--kms-key-id` `--storage-encrypted` `--no-storage-encrypted` **RDS API パラメータ:** `KmsKeyId` `StorageEncrypted` |
| 拡張モニタリング | **拡張モニタリングを有効にして**、DB クラスターが実行されているオペレーティングシステムのメトリック収集をリアルタイムでオンにします。 (詳しくは、「[拡張モニタリングを使用した OS メトリクスのモニタリング](USER_Monitoring.OS.md)」を参照してください。) | **CLI オプション:** `--monitoring-interval` `--monitoring-role-arn` **RDS API パラメータ:** `MonitoringInterval` `MonitoringRoleArn` |
| 初期データベース名: | DB クラスター上のデータベースの名前。名前を指定しないと、Amazon RDS は MySQL の DB クラスターにデータベースを作成しません。ただし、PostgreSQL 用の DB クラスターにはデータベースが作成されます。名前にはデータベースエンジンの予約語を使用できません。DB エンジンによっては、他の制約があります。 MySQL: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/create-multi-az-db-cluster.html) PostgreSQL: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/create-multi-az-db-cluster.html) | **CLI オプション:** `--database-name` **RDS API パラメータ:** `DatabaseName` |
| **ログのエクスポート** | Amazon CloudWatch Logs に発行するデータベースログファイルのタイプ。 詳細については、「[Amazon CloudWatch Logs へのデータベースログの発行](USER_LogAccess.Procedural.UploadtoCloudWatch.md)」を参照してください。 | **CLI オプション:** `-enable-cloudwatch-logs-exports` **RDS API パラメータ:** `EnableCloudwatchLogsExports` |
| メンテナンスウィンドウ | DB クラスターへの変更保留が適用される 30 分単位のウィンドウ。期間が重要ではない場合は、「**No Preference**」 を選択します。 詳細については、「[Amazon RDS メンテナンスウィンドウ](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance)」を参照してください。 | **CLI オプション:** `--preferred-maintenance-window` **RDS API パラメータ:** `PreferredMaintenanceWindow` |
| でマスター認証情報を管理するAWS Secrets Manager | **[Manage master credentials in AWS Secrets Manager]** ( でマスター認証情報を管理する) を選択して、Secrets Manager でユーザーのパスワードをシークレットに管理します。 オプションで、シークレットを保護するために使用する KMS キーを選択します。お客様のアカウントの KMS キーから選択するか、別のアカウントからキーを入力します。 詳細については、「[Amazon RDS および AWS Secrets Manager によるパスワード管理](rds-secrets-manager.md)」を参照してください。 | **CLI オプション:** `--manage-master-user-password \| --no-manage-master-user-password` `--master-user-secret-kms-key-id` **RDS API パラメータ:** `ManageMasterUserPassword` `MasterUserSecretKmsKeyId` |
| マスターパスワード: | マスターユーザーアカウントのパスワード。 | **CLI オプション:** `--master-user-password` **RDS API パラメータ:** `MasterUserPassword` |
| マスターユーザーネーム | すべてのデータベース権限で DB クラスターにログオンするためのマスターユーザー名として使用する名前。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/create-multi-az-db-cluster.html) マルチ AZ DB クラスターの作成後にマスターユーザー名を変更することはできません。 マスターユーザーに付与される権限の詳細については、[マスターユーザーアカウント権限](UsingWithRDS.MasterAccounts.md)を参照してください。 | **CLI オプション:** `--master-username` **RDS API パラメータ:** `MasterUsername` |
| Performance Insights | **Performance Insights を有効にして** DB クラスターのロードをモニタリングし、データベースのパフォーマンスを分析およびトラブルシューティングできるようにします。 保持期間を選択して、保持するパフォーマンスインサイトデータ履歴の量を決定します。保持期間の設定は、**デフォルト (7 日間)** です。パフォーマンスデータをさらに長期間保持するには、1～24 か月を指定します。保持期間の詳細については、「[Performance Insights の料金とデータ保持](USER_PerfInsights.Overview.cost.md)」を参照してください。 このデータベースボリュームの暗号化に使用されるキーを保護するために使用する KMS キーを選択します。お客様のアカウントの KMS キーから選択するか、別のアカウントからキーを入力します。 詳細については、「[Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング](USER_PerfInsights.md)」を参照してください。 | **CLI オプション:** `--enable-performance-insights` `--no-enable-performance-insights` `--performance-insights-retention-period` `--performance-insights-kms-key-id` **RDS API パラメータ:** `EnablePerformanceInsights` `PerformanceInsightsRetentionPeriod` `PerformanceInsightsKMSKeyId` |
| プロビジョンド IOPS | 初めに DB クラスターに割り当てられるプロビジョンド IOPS (1 秒あたりの入力/出力操作数) の合計です。 | **CLI オプション:** `--iops` **RDS API パラメータ:** `Iops` |
| パブリックアクセス | パブリック IP アドレスを DB クラスターに付与する場合は 「**パブリックアクセス可能**」。これにより、VPC 外からアクセス可能になります。パブリックにアクセス可能となるよう、DB クラスターは、VPC のパブリックサブネット内にある必要があります。 VPC 内からのみ DB クラスターにアクセス可能にするには、「**パブリックアクセス不可**」 です。 (詳しくは、「[VPC 内の DB インスタンスをインターネットから隠す](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding)」を参照してください。) VPC の外部から DB クラスターに接続するには、DB クラスターがパブリックにアクセスできる必要があります。また、DB クラスターのセキュリティグループのインバウンドルールを使用してアクセスを許可し、その他の要件を満たしている必要があります。(詳しくは、「[Amazon RDS DB インスタンスに接続できない](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting)」を参照してください。) DB クラスターがパブリックアクセス可能でない場合は、AWS Site-to-Site VPN 接続またはDirect Connect接続を使用してプライベートネットワークからアクセスすることもできます。(詳しくは、「[ネットワーク間のトラフィックのプライバシー](inter-network-traffic-privacy.md)」を参照してください。) | **CLI オプション:** `--publicly-accessible` `--no-publicly-accessible` **RDS API パラメータ:** `PubliclyAccessible` |
| RDS 延長サポート | RDS 標準サポート終了日を過ぎてもサポートされているメジャーエンジンバージョンを 引き続き実行するには、**[RDS 延長サポートを有効にする]** を選択します。 DB クラスターを作成する場合、Amazon RDS はデフォルトで RDS 延長サポートを選択します。RDS の標準サポート終了日後に新しい DB クラスターが作成されて RDS 延長サポートの料金が発生するのを避けるには、この設定を無効にします。既存の DB クラスターについて、RDS 延長サポートの課金開始日以前に料金が発生することはありません。 詳細については、「[Amazon RDS の Amazon RDS 延長サポート](extended-support.md)」を参照してください。 | **CLI オプション:** `--engine-lifecycle-support` **RDS API パラメータ:** `EngineLifecycleSupport` |
| **ストレージスループット** | DB クラスターのストレージスループット値。この設定は、ストレージタイプに汎用 SSD (gp3) を選択した場合にのみ表示されます。 この設定はユーザーが指定した IOPS をもとに自動的に設定され、変更することはできません。 詳細については、「[gp3 ストレージ (推奨)](CHAP_Storage.md#gp3-storage)」を参照してください。 | この値は自動的に計算されます。CLI オプションはありません。 |
| **RDS Proxy** | **[Create an RDS Proxy]** (RDS Proxy の作成) を選択して、DB クラスターにプロキシを作成します。Amazon RDS は、プロキシの IAM ロールと Secrets Manager シークレットを自動的に作成します。 | DB クラスターの作成時には使用できません。 |
| ストレージタイプ | DB クラスターのストレージタイプ。 汎用 SSD (gp3)、プロビジョンド IOPS (io1)、およびプロビジョンド IOPS SSD (io2) ストレージのみがサポートされています。 詳細については、「[Amazon RDS ストレージタイプ](CHAP_Storage.md#Concepts.Storage)」を参照してください。 | **CLI オプション:** `--storage-type` **RDS API パラメータ:** `StorageType` |
| 仮想プライベートクラウド (VPC)。 | この DB クラスターと関連付ける Amazon VPC サービスに基づく VPC。 (詳しくは、「[Amazon VPC と Amazon RDS](USER_VPC.md)」を参照してください。) | CLI と API の場合は、VPC セキュリティグループ ID を指定します。 |
| VPC セキュリティグループ (ファイアウォール) | DB クラスターに関連付けるセキュリティグループ。 (詳しくは、「[VPC セキュリティグループの概要](Overview.RDSSecurityGroups.md#Overview.RDSSecurityGroups.VPCSec)」を参照してください。) | **CLI オプション:** `--vpc-security-group-ids` **RDS API パラメータ:** `VpcSecurityGroupIds` |
## マルチ AZ DB クラスターの作成時に適用されない設定
AWS CLI コマンドの [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)、および RDS API の [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) オペレーションでの以下の設定は、マルチ AZ DB クラスターには適用されません。
コンソールでマルチ AZ DB クラスターにこれらの設定を指定することもできません。
| AWS CLI の設定 | RDS API の設定 |
| --- | --- |
| `--availability-zones` | `AvailabilityZones` |
| `--backtrack-window` | `BacktrackWindow` |
| `--character-set-name` | `CharacterSetName` |
| `--domain` | `Domain` |
| `--domain-iam-role-name` | `DomainIAMRoleName` |
| `--enable-global-write-forwarding \| --no-enable-global-write-forwarding` | `EnableGlobalWriteForwarding` |
| `--enable-http-endpoint \| --no-enable-http-endpoint` | `EnableHttpEndpoint` |
| `--global-cluster-identifier` | `GlobalClusterIdentifier` |
| `--option-group-name` | `OptionGroupName` |
| `--pre-signed-url` | `PreSignedUrl` |
| `--replication-source-identifier` | `ReplicationSourceIdentifier` |
| `--scaling-configuration` | `ScalingConfiguration` |
# Amazon RDS のマルチ AZ DB クラスターへの接続
マルチ AZ DB クラスターには、単一の DB インスタンスではなく、3 つの DB インスタンスがあります。各接続は特定の DB インスタンスで処理されます。マルチ AZ DB クラスターに接続するとき、指定するホスト名とポートは、*エンドポイント*と呼ばれる完全修飾ドメイン名を指します。マルチ AZ DB クラスターは、エンドポイントメカニズムを使用してこれらの接続を抽象化するため、DB クラスター内のどの DB インスタンスに接続するかを正確に指定する必要はありません。そのため、すべてのホスト名をハードコード化したり、一部の DB インスタンスが使用できないときに接続を再ルーティングするための独自のロジックを書いたりする必要はありません。
ライターエンドポイントは、読み取りと書き込みの両方の操作をサポートする DB クラスターのライター DB インスタンスに接続します。リーダーエンドポイントは、読み取り操作のみをサポートする 2 つのリーダー DB インスタンスのいずれかに接続します。
エンドポイントを使用すると、ユースケースに基づいて各接続を対応する DB インスタンスまたは DB インスタンスグループにマッピングできます。例えば、DDL および DML ステートメントを実行するために、ライター DB インスタンスであるどちらの DB インスタンスにも接続できます。クエリを実行するには、リーダーエンドポイントに接続して、マルチ AZ DB クラスターがリーダー DB インスタンス間の接続を自動的に管理するようにします。診断またはチューニングの場合は、特定の DB インスタンスエンドポイントに接続して、特定の DB インスタンスに関する詳細を調査できます。
DB インスタンスへの接続方法については、「[Amazon RDS DB インスタンスへの接続](CHAP_CommonTasks.Connect.md)」を参照ください。
マルチ AZ DB クラスターへの接続の詳細については、以下のトピックを参照してください。
**トピック**
+ [クラスターエンドポイント](#multi-az-db-clusters-concepts-connection-management-endpoints-cluster)
+ [リーダーエンドポイント](#multi-az-db-clusters-concepts-connection-management-endpoints-reader)
+ [インスタンスエンドポイント](#multi-az-db-clusters-concepts-connection-management-endpoints-instance)
+ [高可用性接続](#multi-az-db-clusters-concepts-connection-management-endpoints-ha)
+ [Amazon RDS の AWS ドライバーを使用したマルチ AZ DB クラスターへの接続Amazon Web Services (AWS) JDBC ドライバーを使用したマルチ AZ DB クラスターへの接続](maz-cluster-connect-drivers.md)
## マルチ AZ DB クラスターエンドポイントの種類
エンドポイントは、ホストアドレスを含む一意の ID によって表されます。マルチ AZ DB クラスターでは、以下のタイプのエンドポイントを使用できます。
**クラスターエンドポイント**
マルチ AZ DB クラスターの*クラスターエンドポイント* (または*ライターエンドポイント*) は、その DB クラスターの現在のライター DB インスタンスに接続します。このエンドポイントは、DDL や DML ステートメントなどの書き込みオペレーションを実行できる唯一のエンドポイントです。このエンドポイントは、読み取り操作を実行することもできます。
マルチ AZ DB クラスターごとに 1 つのクラスターエンドポイントと 1 つのライター DB インスタンスがあります。
クラスターエンドポイントは、DB クラスターに対するすべての書き込みオペレーション (挿入、更新、削除、DDL の変更など) で使用します。クラスターエンドポイントは、クエリなどの読み取りオペレーションでも使用できます。
DB クラスターの現在のライター DB インスタンスが失敗した場合、マルチ AZ DB クラスターは新しいライター DB インスタンスに自動的にフェイルオーバーします。フェイルオーバー中、DB クラスターは、新しいライター DB インスタンスからクラスターエンドポイントへの接続リクエストに継続して対応し、サービスの中断は最小限に抑えられます。
次の例では、マルチ AZ DB クラスターのクラスターエンドポイントを示します。
`mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`
クラスターエンドポイントへの接続に関する詳細は、「[クラスターエンドポイント](#multi-az-db-clusters-concepts-connection-management-endpoints-cluster)」を参照してください。
**リーダーエンドポイント**
マルチAZ DB クラスターの*リーダーエンドポイント*は、DB クラスターへの読み取り専用接続をサポートしています。リーダーエンドポイントは、`SELECT` クエリなどの読み取りオペレーションで使用します。このエンドポイントは、リーダー DB インスタンスでこれらのステートメントを処理することにより、ライター DB インスタンスのオーバーヘッドを削減します。また、クラスターが同時`SELECT`クエリを処理する能力を拡張するのにも役立ちます。マルチAZ DBクラスターごとに 1 つのリーダーエンドポイントがあります。
リーダーエンドポイントは、リーダー DB インスタンスの 1 つに各接続リクエストを送信します。セッションにリーダーエンドポイントを使用する場合、そのセッションの`SELECT`などで読み取り専用ステートメントのみを実行できます。
マルチ AZ DB クラスターのリーダーエンドポイントを次の例に示します。リーダーエンドポイントの読み取り専用インテントは、クラスターエンドポイント名内の `-ro` で示されます。
`mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com`
リーダーエンドポイントへの接続に関する詳細は、「[リーダーエンドポイント](#multi-az-db-clusters-concepts-connection-management-endpoints-reader)」を参照してください。
**インスタンスエンドポイント**
*インスタンスエンドポイント*は、マルチ AZ DB クラスター内の特定の DB インスタンスに接続します。DB クラスターの各 DB インスタンスには、独自のインスタンスエンドポイントがあります。したがって、DB クラスター内の現在のライター DB インスタンスに1つのインスタンスエンドポイントがあり、DB クラスター内のリーダー DB ごとに 1 つのインスタンスエンドポイントがあります。
インスタンスエンドポイントは、DB クラスターへの接続の直接制御を提供します。この制御は、クラスターエンドポイントやリーダーエンドポイントの使用が適切でないシナリオに対処するのに役立ちます。例えば、ワークロードタイプに基づき、さらにきめ細かいロードバランシングがアプリケーションに必要になる場合があります。この場合、DB クラスター内の異なるリーダー DB インスタンスに接続して読み取りワークロードを配信するように、複数のクライアントを設定できます。
次の例では、 マルチ AZ DB クラスターの DB インスタンスのインスタンスエンドポイントを示します。
`mydbinstance.123456789012.us-east-1.rds.amazonaws.com`
インスタンスエンドポイントへの接続の詳細については、「[インスタンスエンドポイント](#multi-az-db-clusters-concepts-connection-management-endpoints-instance)」を参照してください。
## エンドポイントの表示
コンソール、AWS CLI、または Amazon RDS API を使用して、クラスター、リーダー、インスタンスエンドポイントを表示します。
------
#### [ Console ]
AWS マネジメントコンソールでは、それぞれのマルチ AZ DB クラスターの詳細ページにクラスターエンドポイントとリーダーエンドポイントが表示されます。インスタンスエンドポイントは、各 DB インスタンスの詳細ページに表示されます。
------
#### [ AWS CLI ]
AWS CLIでは、[describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) コマンドの出力にライターエンドポイントとリーダーエンドポイントが表示されます。例えば、次のコマンドは、現在の AWS リージョンにあるすべてのクラスターのエンドポイント属性を表示します。
```
aws rds describe-db-cluster-endpoints
```
------
#### [ Amazon RDS API ]
Amazon RDS API では、[DescribeDBClusterEndpoints](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterEndpoints.html) アクションを呼び出してエンドポイントを取得します。出力には Amazon Aurora DB クラスターエンドポイントが存在する場合も表示されます。
------
## クラスターエンドポイント
それぞれのマルチ AZ DB クラスターには単一の組み込みクラスターエンドポイントがあり、その名前とその他の属性は Amazon RDS によって管理されます。ユーザーが、この種のエンドポイントを作成、削除、または変更することはできません。
クラスターエンドポイントは、DB クラスターの管理、抽出/変換/ロード (ETL) オペレーションの実行、およびアプリケーションの開発やテストに使用します。クラスターエンドポイントは、クラスターのライター DB インスタンスに接続します。ライター DB インスタンスは、テーブルとインデックスの作成、ステートメント`INSERT`の実行、およびその他の DDL および DML 操作を実行できる唯一の DB インスタンスです。
フェイルオーバーメカニズムが新しい DB インスタンスをクラスターのライター DB インスタンスに昇格させると、クラスターエンドポイントが指す物理 IP アドレスが変更されます。何らかの形式の接続プールや他の多重化を使用している場合は、キャッシュされた DNS 情報の有効時間をフラッシュまたは削減する必要があります。これにより、フェイルオーバー後に使用不可または読み取り専用になった DB インスタンスに読み取り/書き込み接続を試行できないようにします。
## リーダーエンドポイント
マルチ AZ DBクラスターへの読み取り専用接続にはリーダーエンドポイントを使用します。このエンドポイントは、DB クラスターでクエリを大量に消費するワークロードを処理するのに役立ちます。リーダーエンドポイントは、クラスターに対してレポートや他の読み取り専用のオペレーションを実行するアプリケーションに指定します。リーダーエンドポイントは、マルチ AZ DB クラスターで使用可能なリーダーDBインスタンスへの接続を送信します。
それぞれのマルチ AZ クラスターごとに組み込まれている単一のリーダーエンドポイントの名前や他の属性は Amazon RDS で管理されます。ユーザーが、この種のエンドポイントを作成、削除、または変更することはできません。
## インスタンスエンドポイント
マルチ AZ DBクラスターの DB インスタンスごとに個別に組み込まれているインスタンスエンドポイントの名前や他の属性は Amazon RDS で管理されます。ユーザーが、この種のエンドポイントを作成、削除、または変更することはできません。マルチ AZ DB クラスターでは、通常、インスタンスエンドポイントよりもライターエンドポイントとリーダーエンドポイントを頻繁に使用します。
日常的なオペレーションでインスタンスエンドポイントを主に使用するのは、マルチ AZ DBクラスター内の特定の DB インスタンスに影響している容量やパフォーマンスの問題を診断する場合です。特定の DB インスタンスに接続しているときに、そのステータス可変、メトリクスなどを調査できます。これを行うと、クラスター内の他の DB インスタンスで起こっていることは異なる、その DB インスタンスで起こっていることを判断するのに役立ちます。
## 高可用性接続
高可用性が重要であるマルチ AZ DB クラスターでは、ライターエンドポイントを読み取り/書き込み接続や汎用接続に使用し、リーダーエンドポイントを読み取り専用接続に使用します。ライターエンドポイントとリーダーエンドポイントは、インスタンスエンドポイントよりも DB インスタンスのフェイルオーバーを適切に管理します。インスタンスエンドポイントとは異なり、ライターエンドポイントとリーダーエンドポイントは、クラスター内の DB インスタンスが利用できなくなった場合に、接続先の DB インスタンスを自動的に変更します。
DB クラスターのライター DBインスタンスが失敗した場合、 Amazon RDS は新しいライター DB インスタンスに自動的にフェイルオーバーします。これは、リーダー DB インスタンスを新しいライター DB インスタンスに昇格させることによって行われます。フェイルオーバーが発生した場合、ライターエンドポイントを使用して、新しく昇格させたライター DB インスタンスに再接続できます。または、リーダーエンドポイントを使用して DB クラスター内のリーダー DB インスタンスの 1 つに再接続することもできます。フェイルオーバー中に、リーダー DB インスタンスが新しいライター DB インスタンスに昇格された後、リーダーエンドポイントが DB クラスターの新しいライター DB インスタンスへの接続を短時間指示する場合があります。インスタンスエンドポイントへの接続を管理するように独自のアプリケーションロジックを設計する場合は、DB クラスター内の使用可能な DB インスタンスの結果セットを手動またはプログラムで検出できます。
# Amazon RDS の AWS ドライバーを使用したマルチ AZ DB クラスターへの接続
AWS のドライバースイートは、スイッチオーバーとフェイルオーバーの時間の短縮、AWS Secrets Manager、AWS Identity and Access Management (IAM)、フェデレーティッド ID での認証をサポートするように設計されています。AWS ドライバーは、DB クラスターステータスをモニタリングし、クラスタートポロジを認識して新しいライターを決定することを前提としています。このアプローチにより、スイッチオーバーとフェイルオーバーの時間が 1 桁秒に短縮されます (オープンソースドライバーの場合は数十秒)。
新しいサービス機能が導入されるにあたって、こうしたサービス機能を標準でサポートすることが AWS のドライバースイートの目標です。
## Amazon Web Services (AWS) JDBC ドライバーを使用したマルチ AZ DB クラスターへの接続
Amazon Web Services (AWS) JDBC ドライバーは、アプリケーションでクラスター化されたデータベースの機能を利用する際に役立つ高度な JDBC ラッパーとして設計されています。このラッパーは、既存の JDBC ドライバーの機能を補完し、拡張します。このドライバーには、以下のコミュニティドライバーとドロップイン互換性があります。
+ MySQL Connector/J
+ MariaDB Connector/J
+ pgJDBC
AWS JDBC ドライバーをインストールするには、AWS JDBC ドライバーの .jar ファイル (`CLASSPATH` アプリケーション内) を追加して、それぞれのコミュニティドライバーへの参照を保持します。対応する接続 URL プレフィックスを次のように更新します。
+ `jdbc:mysql://`～`jdbc:aws-wrapper:mysql://`
+ `jdbc:mariadb://`～`jdbc:aws-wrapper:mariadb://`
+ `jdbc:postgresql://`～`jdbc:aws-wrapper:postgresql://`
AWS JDBC ドライバーおよびその使用方法の詳細については、「[Amazon Web Services (AWS) JDBC ドライバー GitHub リポジトリ](https://github.com/awslabs/aws-advanced-jdbc-wrapper)」を参照してください。
## Amazon Web Services (AWS) Python ドライバーを使用したマルチ AZ DB クラスターへの接続
Amazon Web Services (AWS) Python ドライバーは、高度な Python ラッパーとして設計されています。このラッパーは、オープンソースの Psycopg ドライバーの機能を補完し、拡張します。AWS Python ドライバーは Python バージョン 3.8 以降をサポートしています。`aws-advanced-python-wrapper` パッケージは、`pip` コマンドと `psycopg` オープンソースパッケージを使用してインストールできます。
AWS Python ドライバーおよびその使用方法の詳細については、「[Amazon Web Services (AWS) Python Driver GitHub repository](https://github.com/awslabs/aws-advanced-python-wrapper)」を参照してください。
# AWS コンピューティングリソースと Amazon RDS のマルチ AZ DB クラスターを自動的に接続する
マルチ AZ DB クラスターと、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスや AWS Lambda 関数などの AWS コンピューティングリソースを自動的に接続できます。
以下のトピックでは、マルチ AZ DB クラスターデプロイ内の Amazon RDS DB インスタンスへの信頼性の高い接続を確立するために、ネットワーク設定、セキュリティグループ、および接続パラメータを設定する詳細な手順について説明します。これらは、マルチ AZ DB クラスターとやり取りするアプリケーションのネットワーク接続とパフォーマンスを最適化し、安全で効率的なデータオペレーションを保証することに重点を置いています。
**Topics**
+ [EC2 インスタンスとマルチ AZ DB クラスターを自動的に接続する](multiaz-ec2-rds-connect.md)
+ [Lambda 関数とマルチ AZ DB クラスターを自動的に接続する](multiaz-lambda-rds-connect.md)
# EC2 インスタンスとマルチ AZ DB クラスターを自動的に接続する
Amazon RDS コンソールを使用して、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとマルチ AZ DB クラスターとの接続を簡単に設定できます。多くの場合、マルチ AZ DB クラスターはプライベートサブネットにあり、EC2 インスタンスは VPC 内のパブリックサブネットにあります。EC2 インスタンスの SQL クライアントを使用すると、マルチ AZ DB クラスターに接続できます。EC2 インスタンスは、プライベートマルチ AZ DB クラスターにアクセスするウェブサーバーやアプリケーションを実行することも可能です。
![\[マルチ AZ DB クラスターを EC2 インスタンスに自動的に接続します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/multi-az-ec2-connect-overview.png)
マルチ AZ DB クラスターと同じ VPC にない EC2 インスタンスに接続する場合は、[VPC の DB インスタンスにアクセスするシナリオ](USER_VPC.Scenarios.md) のシナリオを参照してください。
**Topics**
+ [EC2 インスタンスとの自動接続の概要](#multiaz-ec2-rds-connect-overview)
+ [EC2 インスタンスとマルチ AZ DB クラスターを自動的に接続する](#multiaz-ec2-rds-connect-connecting)
+ [接続中のコンピューティングリソースを表示する](#multiaz-ec2-rds-connect-viewing)
## EC2 インスタンスとの自動接続の概要
EC2 インスタンスとマルチ AZ DB クラスター間の自動接続をセットアップすると、Amazon RDS は、EC2 インスタンスと DB クラスターの VPC セキュリティグループを設定します。
EC2 インスタンスとマルチ AZ DB クラスターを接続するための要件は次のとおりです。
+ EC2 インスタンスはマルチ AZ DB クラスター と同じ VPC に存在する必要があります。
同じ VPC に EC2 インスタンスが存在しない場合、コンソールには EC2 インスタンス作成用のリンクが表示されます。
+ 接続を設定するユーザーには、次の EC2 オペレーションを実行する権限が必要です。
+ `ec2:AuthorizeSecurityGroupEgress`
+ `ec2:AuthorizeSecurityGroupIngress`
+ `ec2:CreateSecurityGroup`
+ `ec2:DescribeInstances`
+ `ec2:DescribeNetworkInterfaces`
+ `ec2:DescribeSecurityGroups`
+ `ec2:ModifyNetworkInterfaceAttribute`
+ `ec2:RevokeSecurityGroupEgress`
EC2 インスタンスへの接続を設定すると、次の表で示されているように、Amazon RDS は、マルチ AZ DB クラスターと EC2 インスタンスに関連付けられているセキュリティグループの現在の設定に従って動作します。
| 現在の RDS セキュリティグループの設定 | 現在の EC2 セキュリティグループの設定 | RDS アクション |
| --- | --- | --- |
| マルチ AZ DB クラスターに関連付けられ、パターン `rds-ec2-n` (`n` は数字) に一致する名前を持つのセキュリティグループが 1 つ以上あります。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、EC2 インスタンスの VPC セキュリティグループをソースとするインバウンドルールが 1 つのみ存在します。 | パターン `rds-ec2-n` (`n` は数字) に一致する名前の EC2 インスタンスに関連付けられたセキュリティグループが 1 つまたは複数存在します。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、ソースとしてのマルチ AZ DB クラスター の VPC セキュリティグループにアウトバウンドルールが 1 つのみ存在します。 | Amazon RDS は何もしません。 EC2 インスタンスとマルチ AZ DB クラスターとの接続は、既に自動で設定されています。EC2 インスタンスと RDS データベースの間には既に接続が存在するため、セキュリティグループは変更されません。 |
| 次の条件のいずれかが適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multiaz-ec2-rds-connect.html) | 次の条件のいずれかが適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multiaz-ec2-rds-connect.html) | [RDS action: create new security groups](ec2-rds-connect.md#rds-action-create-new-security-groups) |
| マルチ AZ DB クラスターに関連付けられ、パターン `rds-ec2-n` に一致する名前を持つセキュリティグループが 1 つ以上あります。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、EC2 インスタンスの VPC セキュリティグループをソースとするインバウンドルールが 1 つのみ存在します。 | EC2 インスタンスに関連付けられた、パターン `ec2-rds-n` に一致する名前のセキュリティグループが 1 つまたは複数存在します。ただし、これらのセキュリティグループは、いずれもマルチ AZ DB クラスターとの接続には使用できません。ソースとしてのマルチ AZ DB クラスター の VPC セキュリティグループにアウトバウンドルールが 1 つも存在しない場合、セキュリティグループを使用できません。また、セキュリティグループが変更されている場合は使用できません。 | [RDS action: create new security groups](ec2-rds-connect.md#rds-action-create-new-security-groups) |
| マルチ AZ DB クラスターに関連付けられ、パターン `rds-ec2-n` に一致する名前を持つセキュリティグループが 1 つ以上あります。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、EC2 インスタンスの VPC セキュリティグループをソースとするインバウンドルールが 1 つのみ存在します。 | 接続に有効な EC2 セキュリティグループは存在しますが、EC2 インスタンスに関連付けられていません。このセキュリティグループには、パターン `rds-ec2-n` に一致する名前が付いています。このセキュリティグループには変更が加えられていません。ソースとしてのマルチ AZ DB クラスター の VPC セキュリティグループにアウトバウンドルールが 1 つのみ存在します。 | [RDS action: associate EC2 security group](ec2-rds-connect.md#rds-action-associate-ec2-security-group) |
| 次の条件のいずれかが適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multiaz-ec2-rds-connect.html) | EC2 インスタンスに関連付けられた、パターン `rds-ec2-n` に一致する名前のセキュリティグループが 1 つまたは複数存在します。パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、ソースとしてのマルチ AZ DB クラスター の VPC セキュリティグループにアウトバウンドルールが 1 つのみ存在します。 | [RDS action: create new security groups](ec2-rds-connect.md#rds-action-create-new-security-groups) |
**RDS アクション: 新しいセキュリティグループを作成する**
Amazon RDS は以下のアクションを実行します。
+ パターン `rds-ec2-n` に一致する新しいセキュリティグループを作成します。このセキュリティグループには、EC2 インスタンスの VPC セキュリティグループをソースとするインバウンドルールが存在します。このセキュリティグループはマルチ AZ DB クラスターに関連付けられていて、これにより、EC2 インスタンスはマルチ AZ DB クラスターにアクセスできます。
+ パターン `ec2-rds-n` に一致する新しいセキュリティグループを作成します。このセキュリティグループには、ソースとしてのマルチ AZ DB クラスター の VPC セキュリティグループにアウトバウンドルールが存在します。このセキュリティグループは EC2 インスタンスに関連付けられ、これにより EC2 インスタンスはマルチ AZ DB クラスターにトラフィックを送信できます。
**RDS アクション: EC2 セキュリティグループを関連付ける**
Amazon RDS は、有効な既存の EC2 セキュリティグループを EC2 インスタンスに関連付けます。このセキュリティグループにより、EC2 インスタンスはマルチ AZ DB クラスターにトラフィックを送信できます。
## EC2 インスタンスとマルチ AZ DB クラスターを自動的に接続する
EC2 インスタンスと RDS データベース との接続を設定する前に、「[EC2 インスタンスとの自動接続の概要](ec2-rds-connect.md#ec2-rds-connect-overview)」で説明されている要件を満たしていることを確認してください。
接続の設定後にこれらのセキュリティグループを変更すると、EC2 インスタンスと RDS データベース との接続に影響する可能性があります。
**注記**
AWS マネジメントコンソール を使用することでのみ、EC2 インスタンスと RDS データベース との接続を自動で設定できます。AWS CLI または RDS API を使用して自動で接続を設定することはできません。
**EC2 インスタンスと RDS データベース を自動的に接続するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[Databases]** (データベース) を選択し、RDS データベース のリンクを選択します。
1. **[アクション]** から **[EC2 接続の設定]** を選択します。
**[Set up EC2 connection]** (EC2 接続の設定) ページが表示されます。
1. **[Set up EC2 connection]** (EC2 接続の設定) ページで、[EC2 instance] (EC2 インスタンス) を選択します。
![\[EC2 接続の設定ページ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/auto-connect-rds-ec2-set-up.png)
同じ VPC に EC2 インスタンスが存在しない場合は、**[Create EC2 instance]** (EC2 インスタンスの作成) を選択します。この場合、新しい EC2 インスタンスが RDS データベース と同じ VPC にあることを確認してください。
1. [**続行**] をクリックしてください。
**[Review and confirm]** (確認と確定) ページが表示されます。
![\[EC2 接続の確認と確定ページ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/auto-connect-rds-ec2-confirm.png)
1. **[Review and confirm]** (確認と確定) ページで、EC2 インスタンスとの接続を設定するために RDS が行う変更を確認します。
変更が正しければ、**[確認とセットアップ]** を選択します。
変更内容が正しくない場合は、**[Previous]** (前へ) または **[Cancel]** (キャンセル) を選択します。
## 接続中のコンピューティングリソースを表示する
AWS マネジメントコンソール を使用して、RDS データベースに接続されているコンピューティングリソースを表示できます。表示されるリソースには、自動的に設定されたコンピューティングリソース接続が含まれます。コンピューティングリソースとの接続は、次の方法で自動的に設定できます。
+ データベースを作成するときに、コンピューティングリソースを選択できます。
詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」および「[Amazon RDS 用のマルチ AZ DB クラスターの作成](create-multi-az-db-cluster.md)」を参照してください。
+ 既存のデータベースとコンピューティングリソース間の接続を設定できます。
詳細については、「[EC2 インスタンスと RDS データベースを自動的に接続する](ec2-rds-connect.md#ec2-rds-connect-connecting)」を参照してください。
コンピューティングリソースリストには、手動でデータベースに接続されたものは含まれていません。例えば、データベースに関連付けられた VPC セキュリティグループにルールを追加することで、コンピューティングリソースがデータベースに手動でアクセスできるようになります。
コンピューティングリソースをリスト化するには、次の条件を満たしている必要があります。
+ コンピューティングリソースに関連付けられているセキュリティグループの名前がパターン `ec2-rds-n` (`n` は数字) と一致する。
+ コンピューティングリソースに関連付けられたセキュリティグループには、ポート範囲が RDS データベースが使用するポートに設定されたアウトバウンドルールがあります。
+ コンピューティングリソースに関連付けられたセキュリティグループには、ソースが RDS データベース に関連付けられたセキュリティグループに設定されたアウトバウンドルールがある。
+ RDS データベースに関連付けられたセキュリティグループの名前が、パターン `rds-ec2-n` (`n` は数字) に一致する。
+ RDS データベース に関連付けられたセキュリティグループには、ポート範囲が RDS データベース が使用するポートに設定されたインバウンドルールがあります。
+ RDS データベース に関連付けられたセキュリティグループには、ソースがコンピューティングリソースに関連付けられたセキュリティグループに設定されたインバウンドルールがある。
**RDS データベースに接続されているコンピューティングリソースを表示するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[Databases]** (データベース) を選択し、RDS データベース の名前を選択します。
1. **[Connectivity & security]** (接続とセキュリティ) タブの **[Connected compute resources]** (接続されたコンピューティングリソース) にコンピューティングリソースが表示されます。
![\[接続中のコンピューティングリソース。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ec2-connected-compute-resources.png)
# Lambda 関数とマルチ AZ DB クラスターを自動的に接続する
RDS コンソールを使用して、Lambda 関数とマルチ AZ DB クラスターとの接続を簡単に設定できます。RDS コンソールを使用して、Lambda 関数とマルチ AZ DB クラスターとの接続を簡単に設定できます。多くの場合、マルチ AZ DB クラスターは、VPC 内のプライベートサブネットにあります。アプリケーションで Lambda 関数を使用すると、プライベートマルチ AZ DB クラスターにアクセスできます。
次の画像は、マルチ AZ DB クラスターと Lambda 関数の間の直接接続を示しています。
![\[マルチ AZ DB クラスターと Lambda 関数を自動的に接続します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/auto-connect-maz-lambda.png)
Lambda 関数とデータベース間の RDS プロキシ経由の接続を設定して、データベースのパフォーマンスと耐障害性を改善できます。多くの場合、Lambda 関数は短いデータベース接続を頻繁に行い、RDS プロキシが提供する接続プールを使用することで利点を得られます。データベース認証情報を Lambda アプリケーションコードで管理する代わりに、Lambda 関数に設定済みの IAM 認証を利用できます。詳細については、「[Amazon RDS Proxy ](rds-proxy.md)」を参照してください。
コンソールを使用して、接続用のプロキシを自動的に作成できます。既存のプロキシを選択することもできます。コンソールはプロキシセキュリティグループを更新して、データベースと Lambda 関数からの接続を許可します。データベースの認証情報を入力するか、データベースへのアクセスに必要な Secrets Manager シークレットを選択できます。
![\[マルチ AZ DB クラスターと Lambda 関数を RDS プロキシ経由で自動的に接続します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/auto-connect-maz-lambda-Proxy.png)
**Topics**
+ [Lambda 関数との自動接続の概要](#multiaz-lambda-rds-connect-overview)
+ [Lambda 関数とマルチ AZ DB クラスターを自動的に接続する](#multiaz-lambda-rds-connect-connecting)
+ [接続中のコンピューティングリソースを表示する](#multiaz-lambda-rds-connect-viewing)
## Lambda 関数との自動接続の概要
Lambda 関数とマルチ AZ DB クラスター間の自動接続をセットアップすると、Amazon RDS は、Lambda 関数と DB クラスター の VPC セキュリティグループを設定します。
Lambda 関数とマルチ AZ DB クラスターを接続するための要件は次のとおりです。
+ Lambda 関数は、マルチ AZ DB クラスターと同じ VPC に存在する必要があります。
同じ VPC に Lambda 関数が存在しない場合、コンソールには Lambda 関数を作成するためのリンクが表示されます。
+ 接続を設定するユーザーには、以下の Amazon RDS、Amazon EC2、Lambda、Secrets Manager、および IAM 操作を実行するアクセス許可が必要です。
+ Amazon RDS
+ `rds:CreateDBProxies`
+ `rds:DescribeDBInstances`
+ `rds:DescribeDBProxies`
+ `rds:ModifyDBInstance`
+ `rds:ModifyDBProxy`
+ `rds:RegisterProxyTargets`
+ Amazon EC2
+ `ec2:AuthorizeSecurityGroupEgress`
+ `ec2:AuthorizeSecurityGroupIngress`
+ `ec2:CreateSecurityGroup`
+ `ec2:DeleteSecurityGroup`
+ `ec2:DescribeSecurityGroups`
+ `ec2:RevokeSecurityGroupEgress`
+ `ec2:RevokeSecurityGroupIngress`
+ Lambda
+ `lambda:CreateFunctions`
+ `lambda:ListFunctions`
+ `lambda:UpdateFunctionConfiguration`
+ Secrets Manager
+ `sercetsmanager:CreateSecret`
+ `secretsmanager:DescribeSecret`
+ IAM
+ `iam:AttachPolicy`
+ `iam:CreateRole`
+ `iam:CreatePolicy`
+ AWS KMS
+ `kms:describeKey`
Lambda 関数とマルチ AZ DB クラスター間の接続をセットアップすると、Amazon RDS は、Lambda 関数とマルチ AZ DB クラスター の VPC セキュリティグループを設定します。RDS プロキシを使用する場合、Amazon RDS はプロキシの VPC セキュリティグループも設定します。Amazon RDS は、次の表で説明されているように、マルチ AZ DB クラスター、Lambda 関数、およびプロキシに関連付けられたセキュリティグループの現在の設定に従って動作します。
| 現在の RDS セキュリティグループの設定 | 現在の Lambda セキュリティグループ設定 | 現在のプロキシセキュリティグループ設定 | RDS アクション |
| --- | --- | --- | --- |
| すべてのリソースのセキュリティグループは正しい命名パターンに従い、適切なインバウンドルールとアウトバウンドルールを持っているため、Amazon RDS は何もしません。 | マルチ AZ DB クラスターに関連付けられ、パターン `rds-lambda-n` (`n` は数字) に一致する名前を持つのセキュリティグループが 1 つ以上あります (または関連するプロキシの `TargetHealth` が `AVAILABLE` の場合)。 パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、Lambda 関数またはプロキシの VPC セキュリティグループをソースとするインバウンドルールが 1 つのみ存在します。 | Lambda 関数に関連付けられたセキュリティグループが 1 つ以上あり、その名前はパターン `lambda-rds-n` または `lambda-rdsproxy-n` (`n` は数字) に一致します。 パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、マルチ AZ DB クラスターまたはプロキシの VPC セキュリティグループをデスティネーションとするアウトバウンドルールが 1 つのみ存在します。 | プロキシに関連付けられたセキュリティグループが 1 つ以上あり、その名前はパターン `rdsproxy-lambda-n` (`n` は数字) に一致します。 パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、Lambda 関数とマルチ AZ DB クラスターの VPC セキュリティグループに関するインバウンドルールとアウトバウンドルールがあります。 |
| 次の条件のいずれかが適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html) Amazon RDS は、Lambda 関数またはプロキシの VPC セキュリティグループをソースとするインバウンドルールが 1 つも存在しないセキュリティグループを使用できません。また、Amazon RDS は、変更されたセキュリティグループを使用できません。変更の例としては、ルールの追加や、既存ルールのポート変更などがあります。 | 次の条件のいずれかが適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html) Amazon RDS は、マルチ AZ DB クラスターまたはプロキシの VPC セキュリティグループをソースとするアウトバウンドルールが 1 つも存在しない場合、セキュリティグループを使用できません。また、Amazon RDS は、変更されたセキュリティグループを使用できません。 | 次の条件のいずれかが適用されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html)Amazon RDS は、マルチ AZ DB クラスターおよび Lambda 関数の VPC セキュリティグループに関するインバウンドルールとアウトバウンドルールがないセキュリティグループを使用できません。また、Amazon RDS は、変更されたセキュリティグループを使用できません。 | [RDS action: create new security groups](#maz-lam-action-create-new-security-groups) |
| マルチ AZ DB クラスターに関連付けられ、パターン `rds-lambda-n` に一致する名前を持つセキュリティグループはありません (または関連するプロキシの `TargetHealth` が `AVAILABLE` の場合)。 パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、Lambda 関数またはプロキシの VPC セキュリティグループをソースとするインバウンドルールが 1 つのみ存在します。 | Lambda 関数に関連付けられたセキュリティグループが 1 つ以上あり、その名前はパターン `lambda-rds-n` または `lambda-rdsproxy-n` に一致します。 ただし、Amazon RDS は、これらのセキュリティグループをルチ AZ DB クラスターとの接続に使用できません。Amazon RDS は、マルチ AZA DB クラスターまたはプロキシの VPC セキュリティグループをデスティネーションとするアウトバウンドルールが 1 つもないセキュリティグループを使用できません。また、Amazon RDS は、変更されたセキュリティグループを使用できません。 | プロキシに関連付けられ、パターン `rdsproxy-lambda-n` に一致する名前のセキュリティグループが 1 つ以上あります。 ただし、Amazon RDS は、マルチ AZ DB クラスターまたは Lambda 関数との接続にこれらのセキュリティグループを使用できません。Amazon RDS は、マルチ AZ DB クラスターおよび Lambda 関数の VPC セキュリティグループに関するインバウンドルールとアウトバウンドルールがないセキュリティグループを使用できません。また、Amazon RDS は、変更されたセキュリティグループを使用できません。 | [RDS action: create new security groups](#maz-lam-action-create-new-security-groups) |
| マルチ AZ DB クラスターに関連付けられ、パターン `rds-lambda-n` に一致する名前を持つセキュリティグループはありません (または関連するプロキシの `TargetHealth` が `AVAILABLE` の場合)。 パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、Lambda 関数またはプロキシの VPC セキュリティグループをソースとするインバウンドルールが 1 つのみ存在します。 | 接続用の有効な Lambda セキュリティグループが存在しますが、Lambda 関数に関連付けられていません。このセキュリティグループには、パターン `lambda-rds-n` または `lambda-rdsproxy-n` に一致する名前が付いています。このセキュリティグループには変更が加えられていません。マルチ AZ DB クラスターまたはプロキシの VPC セキュリティグループをデスティネーションとするアウトバウンドルールが 1 つだけあります。 | 接続に有効なプロキシセキュリティグループは存在しますが、プロキシに関連付けられていません。このセキュリティグループには、パターン `rdsproxy-lambda-n` に一致する名前が付いています。このセキュリティグループには変更が加えられていません。マルチ AZ DB クラスターと Lambda 関数の VPC セキュリティグループに関するインバウンドルールとアウトバウンドルールがあります。 | [RDS action: associate Lambda security group](#maz-lam-action-associate-lam-security-group) |
| 次の条件のいずれかが適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html) | Lambda 関数に関連付けられたセキュリティグループが 1 つ以上あり、その名前はパターン `lambda-rds-n` または `lambda-rdsproxy-n` に一致します。 パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、マルチ AZ DB クラスターまたはプロキシの VPC セキュリティグループをデスティネーションとするアウトバウンドルールが 1 つだけ存在します。 | プロキシに関連付けられ、パターン `rdsproxy-lambda-n` に一致する名前のセキュリティグループが 1 つ以上あります。 パターンに一致するセキュリティグループは変更されていません。このセキュリティグループには、マルチ AZ DB クラスターと Lambda 関数の VPC セキュリティグループに関するインバウンドルールとアウトバウンドルールがあります。 | [RDS action: create new security groups](#maz-lam-action-create-new-security-groups) |
| マルチ AZ DB クラスターに関連付けられ、パターン `rds-rdsproxy-n` (`n` は数字) に一致する名前を持つのセキュリティグループが 1 つ以上あります。 | 次の条件のいずれかが適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html) Amazon RDS は、マルチ AZA DB クラスターまたはプロキシの VPC セキュリティグループをデスティネーションとするアウトバウンドルールが 1 つもないセキュリティグループを使用できません。また、Amazon RDS は、変更されたセキュリティグループを使用できません。 | 次の条件のいずれかが適用されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multiaz-lambda-rds-connect.html)Amazon RDS は、マルチ AZ DB クラスターおよび Lambda 関数の VPC セキュリティグループに関するインバウンドルールとアウトバウンドルールがないセキュリティグループを使用できません。また、Amazon RDS は、変更されたセキュリティグループを使用できません。 | [RDS action: create new security groups](#maz-lam-action-create-new-security-groups) |
**RDS アクション: 新しいセキュリティグループを作成する**
Amazon RDS は以下のアクションを実行します。
+ パターン `rds-lambda-n` に一致する新しいセキュリティグループを作成します。このセキュリティグループには、Lambda 関数またはプロキシの VPC セキュリティグループをソースとするインバウンドルールがあります。このセキュリティグループはマルチ AZ DB クラスターに関連付けられていて、これにより、関数またはプロキシがマルチ AZ DB クラスターにアクセスするのを許可します。
+ パターン `lambda-rds-n` に一致する新しいセキュリティグループを作成します。このセキュリティグループには、マルチ AZ DB クラスターまたはプロキシの VPC セキュリティグループをデスティネーションとするアウトバウンドルールがあります。このセキュリティグループは Lambda 関数に関連付けられ、Lambda 関数がマルチ AZ DB クラスターにトラフィックを送信するか、プロキシ経由でトラフィックを送信することを許可します。
+ パターン `rdsproxy-lambda-n` に一致する新しいセキュリティグループを作成します。このセキュリティグループには、マルチ AZ DB クラスターと Lambda 関数の VPC セキュリティグループに関するインバウンドルールとアウトバウンドルールがあります。
**RDS アクション: Lambda セキュリティグループを関連付ける**
Amazon RDS は、有効な既存の Lambda セキュリティグループを Lambda 関数に関連付けます。このセキュリティグループは、関数がマルチ AZ DB クラスター にトラフィックを送信するか、プロキシ経由でトラフィックを送信することを許可します。
## Lambda 関数とマルチ AZ DB クラスターを自動的に接続する
Amazon RDS コンソールを使用して、Lambda 関数をマルチ AZ DB クラスターに自動的に接続することができます。これにより、これらのリソース間の接続を設定するプロセスが簡単になります。
RDS プロキシを使用して、接続にプロキシを含めることもできます。Lambda 関数は短いデータベース接続を頻繁に行うため、RDS プロキシが提供する接続プールを使用することで利点を得られます。Lambda アプリケーションコードでデータベース認証情報を管理する代わりに、Lambda 関数用に設定済みの IAM 認証を使用することもできます。
**[Lambda 接続の設定]** ページを使用して、既存のマルチ AZ DB クラスターを新規および既存の Lambda 関数に接続できます。セットアッププロセスでは、必要なセキュリティグループが自動的にセットアップされます。
Lambda 関数とマルチ AZ DB クラスターの間の接続を設定する前に、次のことを確認してください。
+ Lambda 関数とマルチ AZ DB クラスターが同じ VPC にあります。
+ ユーザーアカウントに適切なアクセス許可があります。要件の詳細については、「[Lambda 関数との自動接続の概要](lambda-rds-connect.md#lambda-rds-connect-overview)」を参照してください。
接続の設定後にセキュリティグループを変更すると、Lambda 関数とマルチ AZ DB クラスターとの接続に影響する可能性があります。
**注記**
AWS マネジメントコンソール でのみ、マルチ AZ DB クラスターと Lambda 関数の間の接続を自動的に設定できます。Lambda 関数を接続するには、マルチ AZ DB クラスターのすべてのインスタンスが**使用可能**状態である必要があります。
**Lambda 関数とマルチ AZ DB クラスターを自動的に接続するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[データベース]** を選択し、Lambda 関数に接続するマルチ AZ DB クラスターを選択します。
1. **[アクション]** として、**[Lambda 接続の設定]** を選択します。
1. **[Lambda 接続の設定]** ページの **[Lambda 関数の選択]** で、次のいずれかを実行します。
+ マルチ AZ DB クラスターと同じ VPC に既存の Lambda 関数がある場合は、**[既存の関数を選択]** を選択し、関数を選択します。
+ 同じ VPC に Lambda 関数がない場合は、**[新しい関数を作成]** を選択し、**[関数名]** を入力します。デフォルトのランタイムは Nodejs.18 に設定されています。接続設定が完了した後、Lambda コンソールで新しい Lambda 関数の設定を変更できます。
1. (オプション) **[RDS プロキシ]** で、**[RDS プロキシを使用して接続]** を選択し、次のいずれかを実行します。
+ 使用する既存のプロキシがある場合は、**[既存のプロキシを選択]** を選択し、プロキシを選択します。
+ プロキシがなく、Amazon RDS にプロキシを自動的に作成させる場合は、**[新しいプロキシの作成]** を選択します。次に、**[データベース認証情報]** として、次のいずれかを実行します。
1. **[データベースのユーザー名とパスワード]** を選択し、マルチ AZ DB クラスターの **[ユーザー名]** と **[パスワード]** を入力します。
1. **[Secrets Manager シークレット]** を選択します。次に、**[シークレットを選択]** で、AWS Secrets Manager シークレットを選択します。Secrets Manager シークレットがない場合は、**[新しい Secrets Manager シークレットを作成]** を選択して、[新しいシークレットを作成](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)します。シークレットを作成した後、**[シークレットを選択]** で、新しいシークレットを選択します。
新しいプロキシを作成した後、**[既存のプロキシを選択]** を選択し、プロキシを選択します。プロキシが接続可能になるまでに時間がかかる場合があることに注意してください。
1. (オプション) **[接続の概要]** を展開し、強調表示されているリソースの最新情報を確認します。
1. **[設定]** を選択します。
設定を確認した後、Amazon RDS は、Lambda 関数、RDS プロキシ (プロキシを使用した場合)、およびマルチ AZ DB クラスターの接続プロセスを開始します。コンソールに **[接続の詳細]** ダイアログボックスが表示され、リソース間の接続を許可するセキュリティグループの変更が一覧表示されます。
## 接続中のコンピューティングリソースを表示する
AWS マネジメントコンソール を使用して、マルチ AZ DB クラスターに接続されているコンピューティングリソースを表示できます。表示されるリソースには、Amazon RDS が自動的に設定したコンピューティングリソース接続が含まれます。
一覧表示されるコンピューティングリソースには、マルチ AZ DB クラスターに手動で接続されたリソースは含まれていません。例えば、クラスターに関連付けられた VPC セキュリティグループにルールを追加することで、コンピューティングリソースがマルチ AZ DB クラスター に手動でアクセスするのを許可できます。
コンソールに Lambda 関数を一覧表示するには、以下の条件が適用される必要があります。
+ コンピューティングリソースに関連付けられているセキュリティグループの名前がパターン `lambda-rds-n` または `lambda-rdsproxy-n` (`n` は数字) と一致します。
+ コンピューティングリソースに関連付けられているセキュリティグループに、マルチ AZ DB クラスターまたは該当するプロキシが使用するポートにポート範囲が設定されたアウトバウンドルールがあります。アウトバウンドルールのデスティネーションは、マルチ AZ DB クラスターまたは関連するプロキシに関連付けられているセキュリティグループに設定されている必要があります。
+ データベースに関連付けられたプロキシにアタッチされたセキュリティグループの名前は、パターン `rds-rdsproxy-n` (`n` は数字) と一致します。
+ 関数に関連付けられているセキュリティグループには、マルチ AZ DB クラスターまたは該当するプロキシが使用するポートにポート範囲が設定されたアウトバウンドルールがあります。デスティネーションは、マルチ AZ DB クラスターまたは関連するプロキシに関連付けられているセキュリティグループに設定されている必要があります。
**マルチ AZ DB クラスターに自動的に接続されたコンピューティングリソースを表示するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[データベース]** を選択し、マルチ AZ DB クラスターを選択します。
1. **[接続とセキュリティ]** タブの **[接続されたコンピューティングリソース]** にコンピューティングリソースが表示されます。
# Amazon RDS のマルチ AZ DB クラスターの変更
マルチ AZ DB クラスターには、3 つの別々のアベイラビリティーゾーンに 1 つのライターDB インスタンスと 2 つのリーダー DB インスタンスがあります。マルチ AZ DB クラスターは、マルチ AZ 配置と比較して、高可用性、読み取りワークロードの容量の増加、および低レイテンシーを提供します。マルチ AZ DBクラスターの詳細ついては、「[Amazon RDS のマルチ AZ DB クラスターデプロイ](multi-az-db-clusters-concepts.md)」を参照してください。
マルチ AZ DB クラスターを変更して、設定を変更することができます。スナップショットの作成など、マルチ AZ DB クラスターで操作を実行することもできます。
**重要**
マルチ AZ DB クラスター内の DB インスタンスは変更できません。変更はすべて DB クラスターレベルで行う必要があります。マルチ AZ DB クラスター内の DB インスタンスで実行できるのは、再起動のみです。
マルチ AZ DB クラスターは、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して変更できます。
## コンソール
**マルチ DB クラスターを変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、「**データベース**」 を選択し、変更したいマルチ AZ DB クラスターを選択します。
1. [**Modify**] を選択します。[**DB クラスターの変更**] ページが表示されます。
1. 必要に応じて任意の設定を変更してください。各設定の詳細については、「[マルチ AZ DB クラスターの変更の設定](#modify-multi-az-db-cluster-settings)」を参照してください。
1. すべての変更が正しいことを確認したら、[**Continue**] を選択して変更の概要を確認します。
1. (省略可能) 変更をすぐに適用するには、[**すぐに適用**] を選択します。このオプションを選択すると、ダウンタイムを発生させる場合があります。(詳しくは、「[今すぐ変更を適用する](#modify-multi-az-db-cluster-apply-immediately)」を参照してください。)
1. 確認ページで、変更内容を確認します。正しい場合は、「**DB クラスターの変更**」を選択して変更を保存します。
または、[**戻る**] を選択して変更を編集するか、**キャンセル**を選択して変更をキャンセルします。
## AWS CLI
AWS CLIを使用してマルチAZ DBクラスターを変更するには、[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを呼び出します。DB クラスター識別子と、変更したいオプションの値を指定します。各オプションの詳細については、「[マルチ AZ DB クラスターの変更の設定](#modify-multi-az-db-cluster-settings)」を参照してください。
**Example**
次のコードでは、バックアップ保存期間を 1 週間 (7 日間) に設定して、`my-multi-az-dbcluster` を変更します。このコードは、`--deletion-protection` を使用して削除保護を有効にします。`--no-deletion-protection`を使用して、削除保護を無効にするには、変更は、`--no-apply-immediately` を使用して次のメンテナンスウィンドウ中に適用されます。今すぐ変更を適用するには、`--apply-immediately` を使用します。詳細については、「[今すぐ変更を適用する](#modify-multi-az-db-cluster-apply-immediately)」を参照してください。
Linux、macOS、Unix の場合:
```
aws rds modify-db-cluster \
--db-cluster-identifier my-multi-az-dbcluster \
--backup-retention-period 7 \
--deletion-protection \
--no-apply-immediately
```
Windows の場合:
```
aws rds modify-db-cluster ^
--db-cluster-identifier my-multi-az-dbcluster ^
--backup-retention-period 7 ^
--deletion-protection ^
--no-apply-immediately
```
## RDS API
Amazon RDS API を使用して マルチAZ DB クラスターを変更するには、[ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) オペレーションを呼び出します。DB クラスター識別子と、変更したい設定のパラメータを指定します。各パラメータの詳細については、「[マルチ AZ DB クラスターの変更の設定](#modify-multi-az-db-cluster-settings)」を参照してください。
## 今すぐ変更を適用する
マルチ AZ DB クラスターを変更する際に、変更内容を即時に適用することができます。変更をすぐに適用するには、AWS マネジメントコンソール で [**Apply Immediately (すぐに適用)**] オプションを選択します。または、AWS CLI を呼び出す際に`--apply-immediately`オプションを使用するか、`true`Amazon RDS API を使用する際に`ApplyImmediately`のパラメータを設定します。
変更の即時適用を選択しない場合、この変更は保留中の変更キューに保存されます。次のメンテナンスウィンドウ実行中に、キューのすべての保留中の変更が適用されます。変更の即時適用を選択した場合は、新しい変更と、保留中の変更キューにあるすべての変更が適用されます。
**重要**
保留中の変更のいずれかで DB クラスターをテンポラリに使用不可にする必要がある場合 (ダウンタイム)、*すぐに適用*オプションを選択すると、予期しないダウンタイムが発生する可能性があります。
変更をすぐに適用することを選択した場合、保留中の変更も、次のメンテナンス時間中ではなく、すぐに適用されます。
次のメンテナンスウィンドウで保留中の変更を適用しない場合は、変更を元に戻すように DB インスタンスを変更できます。これを行うには、AWS CLI を使用し、`--apply-immediately` オプションを指定します。
変更の延期を選択した場合でも、一部のデータベース設定に対する変更は即時に適用されます。さまざまなデータベース設定が [Apply immediately (すぐに適用)] の設定とどのように相互作用するかについては、「[マルチ AZ DB クラスターの変更の設定](#modify-multi-az-db-cluster-settings)」を参照してください。
## マルチ AZ DB クラスターの変更の設定
マルチ AZ DB クラスターの変更に使用できる設定の詳細については、次の表を参照してください。AWS CLIのオプションの詳細については、[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)を参照してください。RDS API パラメータの詳細については、[ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)を参照してください。
| コンソール設定 | 設定の説明 | CLI オプションと RDS API パラメータ | 変更を行った場合 | ダウンタイムに関する注意 |
| --- | --- | --- | --- | --- |
| **ストレージ割り当て** | DB クラスター内の各 DB インスタンスに割り当てるストレージの量 (ギビバイト単位)。(詳しくは、「[Amazon RDS DB インスタンスストレージ](CHAP_Storage.md)」を参照してください。) | **CLI オプション:** `--allocated-storage` **RDS API パラメータ:** `AllocatedStorage` | 変更をすぐに適用するように選択した場合は、直ちに適用されます。 変更をすぐに適用ように選択しない場合は、次のメンテナンス期間中に適用されます。 | この変更時にダウンタイムは発生しません。 |
| マイナーバージョン自動アップグレード | **自動マイナーバージョンアップグレード**を有効にして、DB クラスターが優先マイナー DB エンジンバージョンアップグレードを利用可能になったときに自動的に受信するようにします。Amazon RDS では、メンテナンスウィンドウでマイナーバージョンの自動アップグレードが実行されます。 | **CLI オプション:** `--auto-minor-version-upgrade` `--no-auto-minor-version-upgrade` **RDS API パラメータ:** `AutoMinorVersionUpgrade` | 変更はただちに発生します。この設定は、[Apply immediately (すぐに適用)] 設定を無視します。 | この変更中に、ダウンタイムが発生します。 |
| バックアップの保存期間 | DB クラスターの自動バックアップを保持する日数。この値はゼロより大きくなければなりません。 詳細については、「[バックアップの概要](USER_WorkingWithAutomatedBackups.md)」を参照してください。 | **CLI オプション:** `--backup-retention-period` **RDS API パラメータ:** `BackupRetentionPeriod` | 変更をすぐに適用するように選択した場合は、直ちに適用されます。 変更をすぐに適用ように選択しない場合は、次のメンテナンス期間中に適用されます。 | この変更時にダウンタイムは発生しません。 |
| バックアップ期間: | Amazon RDS が DB クラスターのバックアップを自動的に作成する期間。データベースのバックアップを保持する期間を指定しない場合は、デフォルトの「**指定なし**」 を使用します。 詳細については、「[バックアップの概要](USER_WorkingWithAutomatedBackups.md)」を参照してください。 | **CLI オプション:** `--preferred-backup-window` **RDS API パラメータ:** `PreferredBackupWindow` | 変更は、可能な限り早く非同期的に適用されます。 | この変更時にダウンタイムは発生しません。 |
| **認証局** | DB クラスターによって使用されるサーバー証明書の認定機関 (CA)。 詳細については、「[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md)」を参照してください。 | **CLI オプション:** `--ca-certificate-identifier` **RDS API パラメータ:** `CACertificateIdentifier` | 変更をすぐに適用するように選択した場合は、直ちに適用されます。 変更をすぐに適用ように選択しない場合は、次のメンテナンス期間中に適用されます。 | ダウンタイムは、DB エンジンが再起動なしのローテーションをサポートしていない場合にのみ発生します。[describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI コマンドを使用すると、DB エンジンが再起動なしのローテーションをサポートしているかどうかを判断できます。 |
| Copy tags to snapshots | このオプションは、DB スナップショットの作成時に、DB クラスターの任意のタグを、そのスナップショットにコピーします。 (詳しくは、「[ Amazon RDS リソースのタグ付け](USER_Tagging.md)」を参照してください。) | **CLI オプション:** `-copy-tags-to-snapshot` `-no-copy-tags-to-snapshot` **RDS API パラメータ:** `CopyTagsToSnapshot` | 変更はただちに発生します。この設定は、[Apply immediately (すぐに適用)] 設定を無視します。 | この変更時にダウンタイムは発生しません。 |
| データベース認証 | マルチ AZ DB クラスターの場合、**パスワード認証**のみがサポートされています。 | パスワード認証がデフォルトであるため、なし。 | 変更をすぐに適用するように選択した場合は、直ちに適用されます。 変更をすぐに適用ように選択しない場合は、次のメンテナンス期間中に適用されます。 | この変更時にダウンタイムは発生しません。 |
| **DB cluster identifier (DB クラスター識別子** | DB クラスター識別子。この値は小文字で保存されます。 DB クラスター識別子を変更すると、DB クラスターエンドポイントが変更されます。DB クラスター内の識別子とエンドポイントも変更されます。新しい DB クラスタークラスターの名前は一意である必要があります。最大長は 63 文字です。 DB クラスター内の DB インスタンスの名前が、DB クラスターの新しい名前に対応するように変更されます。新しい DB インスタンスと既存の DB インスタンスを同じ名前にすることはできません。例えば、DB クラスターの名前を `maz` に変更すると、DB インスタンス名は `maz-instance-1` に変更されることがあります。この場合、`maz-instance-1` という名前の既存の DB インスタンスは存在できません。 詳細については、「[Amazon RDS のマルチ AZ DB クラスターの名前の変更](multi-az-db-cluster-rename.md)」を参照してください。 | **CLI オプション:** `--new-db-cluster-identifier` **RDS API パラメータ:** `NewDBClusterIdentifier` | 変更をすぐに適用するように選択した場合は、直ちに適用されます。 変更をすぐに適用ように選択しない場合は、次のメンテナンス期間中に適用されます。 | この変更時にダウンタイムは発生しません。 |
| DB クラスターインスタンスクラス | マルチ AZ DB クラスター内の各 DB インスタンス (`db.r6gd.xlarge`など) の計算容量とメモリ容量。 可能であれば、一般的なクエリの作業セットをメモリに保持できる十分な大きさの DB インスタンスクラスを選択します。作業セットがメモリに保持されていると、システムによるディスクへの書き込みが回避され、これによりパフォーマンスが向上します。 詳細については、「[マルチ AZ DB クラスターで利用できるインスタンスクラス](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts.InstanceAvailability)」を参照してください。 | **CLI オプション:** `--db-cluster-instance-class` **RDS API パラメータ:** `DBClusterInstanceClass` | 変更をすぐに適用するように選択した場合は、直ちに適用されます。 変更をすぐに適用ように選択しない場合は、次のメンテナンス期間中に適用されます。 | この変更中に、ダウンタイムが発生します。 |
| **DB クラスターのパラメータグループ** | DB クラスターに関連付ける DB クラスターのパラメータグループ。 (詳しくは、「[マルチ AZ DB クラスターのパラメータグループ](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups)」を参照してください。) | **CLI オプション:** `--db-cluster-parameter-group-name` **RDS API パラメータ:** `DBClusterParameterGroupName` | パラメータグループの変更は直ちに行われます。 | この変更時にダウンタイムは発生しません。パラメータグループを変更すると、一部のパラメータの変更は、再起動なしで マルチ AZ DB クラスター内の DB インスタンスに即時に適用されます。他のパラメータへの変更は、DB インスタンスの再起動後にのみ適用されます。 |
| DB エンジンバージョン | 使用するデータベースエンジンのバージョン。 | **CLI オプション:** `--engine-version` **RDS API パラメータ:** `EngineVersion` | 変更をすぐに適用するように選択した場合は、直ちに適用されます。 変更をすぐに適用ように選択しない場合は、次のメンテナンス期間中に適用されます。 | この変更中に、ダウンタイムが発生します。 |
| 削除保護 | **削除保護を有効**にして、DB クラスターが削除されないようにします。 (詳しくは、「[DB インスタンスを削除する](USER_DeleteInstance.md)」を参照してください。) | **CLI オプション:** `--deletion-protection` `--no-deletion-protection` **RDS API パラメータ:** `DeletionProtection` | 変更はただちに発生します。この設定は、[Apply immediately (すぐに適用)] 設定を無視します。 | この変更時にダウンタイムは発生しません。 |
| メンテナンスウィンドウ | DB クラスターへの変更保留が適用される 30 分単位のウィンドウ。期間が重要ではない場合は、「**No Preference**」 を選択します。 詳細については、「[Amazon RDS メンテナンスウィンドウ](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance)」を参照してください。 | **CLI オプション:** `--preferred-maintenance-window` **RDS API パラメータ:** `PreferredMaintenanceWindow` | 変更はただちに発生します。この設定は、[Apply immediately (すぐに適用)] 設定を無視します。 | ダウンタイムを引き起こす保留中のアクションが 1 つ以上あり、現在の時刻を含むようにメンテナンス時間を変更した場合、それらの保留中のアクションはすぐに適用され、ダウンタイムが発生します。 |
| でマスター認証情報を管理するAWS Secrets Manager | **[Manage master credentials in AWS Secrets Manager]** ( でマスター認証情報を管理する) を選択して、Secrets Manager でユーザーのパスワードをシークレットに管理します。 オプションで、シークレットを保護するために使用する KMS キーを選択します。お客様のアカウントの KMS キーから選択するか、別のアカウントからキーを入力します。 RDS によって既に DB クラスターのマスターユーザーのパスワードを管理している場合は、**[Rotate secret immediately]** (すぐにシークレットをローテーションする) を選択してマスターユーザーパスワードをすぐにローテーションできます。 詳細については、「[Amazon RDS および AWS Secrets Manager によるパスワード管理](rds-secrets-manager.md)」を参照してください。 | **CLI オプション:** `--manage-master-user-password \| --no-manage-master-user-password` `--master-user-secret-kms-key-id` `--rotate-master-user-password \| --no-rotate-master-user-password` **RDS API パラメータ:** `ManageMasterUserPassword` `MasterUserSecretKmsKeyId` `RotateMasterUserPassword` | マスターユーザーパスワードの自動管理をオンまたはオフにすると、すぐに変更が行われます。この変更は、[Apply immediately] (すぐに適用) の設定を無視します。 マスターユーザーのパスワードをローテーションする場合は、変更がすぐに適用されるように指定する必要があります。 | この変更時にダウンタイムは発生しません。 |
| 新しいマスターパスワード | マスターユーザーアカウントのパスワード。 | **CLI オプション:** `--master-user-password` **RDS API パラメータ:** `MasterUserPassword` | 変更は、可能な限り早く非同期的に適用されます。この設定は、[Apply immediately (すぐに適用)] 設定を無視します。 | この変更時にダウンタイムは発生しません。 |
| プロビジョンド IOPS | 初めに DB クラスターに割り当てられるプロビジョンド IOPS (1 秒あたりの入力/出力操作数) の合計です。 | **CLI オプション:** `--iops` **RDS API パラメータ:** `Iops` | 変更をすぐに適用するように選択した場合は、直ちに適用されます。 変更をすぐに適用ように選択しない場合は、次のメンテナンス期間中に適用されます。 | この変更時にダウンタイムは発生しません。 |
| パブリックアクセス | パブリック IP アドレスを DB クラスターに付与する場合は **パブリックアクセス可能** を選択します。これにより、DB インスタンスは Virtual Private Cloud (VPC) 外からアクセス可能になります。パブリックにアクセス可能となるよう、DB クラスターは、VPC のパブリックサブネット内にある必要があります。 VPC 内からのみ DB クラスターにアクセス可能にするには、「**パブリックアクセス不可**」 です。 (詳しくは、「[VPC 内の DB インスタンスをインターネットから隠す](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding)」を参照してください。) VPC の外部から DB クラスターに接続するには、DB クラスターがパブリックにアクセスできる必要があります。また、DB クラスターのセキュリティグループのインバウンドルールを使用してアクセスを許可し、その他の要件を満たしている必要があります。(詳しくは、「[Amazon RDS DB インスタンスに接続できない](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting)」を参照してください。) DB クラスターがパブリックアクセス可能でない場合は、AWS Site-to-Site VPN 接続またはDirect Connect接続を使用してプライベートネットワークからアクセスすることもできます。詳細については、「[ネットワーク間のトラフィックのプライバシー](inter-network-traffic-privacy.md)」を参照してください。 | DB クラスターの変更時には使用できません。 | 変更はただちに発生します。この設定は、[Apply immediately (すぐに適用)] 設定を無視します。 | この変更時にダウンタイムは発生しません。 |
| ストレージタイプ | DB クラスターのストレージタイプ。 汎用 SSD (gp3)、プロビジョンド IOPS (io1)、およびプロビジョンド IOPS SSD (io2) ストレージのみがサポートされています。 詳細については、「[Amazon RDS ストレージタイプ](CHAP_Storage.md#Concepts.Storage)」を参照してください。 | **CLI オプション:** `--storage-type` **RDS API パラメータ:** `StorageType` | 変更をすぐに適用するように選択した場合は、直ちに適用されます。 変更をすぐに適用ように選択しない場合は、次のメンテナンス期間中に適用されます。 | この変更時にダウンタイムは発生しません。 |
| VPC セキュリティグループ | DB クラスターに関連付けるセキュリティグループ。 (詳しくは、「[VPC セキュリティグループの概要](Overview.RDSSecurityGroups.md#Overview.RDSSecurityGroups.VPCSec)」を参照してください。) | **CLI オプション:** `--vpc-security-group-ids` **RDS API パラメータ:** `VpcSecurityGroupIds` | 変更は、可能な限り早く非同期的に適用されます。この設定は、[Apply immediately (すぐに適用)] 設定を無視します。 | この変更時にダウンタイムは発生しません。 |
## マルチ AZ DB クラスターの変更時に適用されない設定
AWS CLI コマンド [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) および RDS API オペレーション [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) の次の設定は、マルチAZ DBクラスターには適用されません。
コンソールでマルチ AZ DB クラスターの設定を変更することもできません。
| AWS CLI の設定 | RDS API の設定 |
| --- | --- |
| `--backtrack-window` | `BacktrackWindow` |
| `--cloudwatch-logs-export-configuration` | `CloudwatchLogsExportConfiguration` |
| `--copy-tags-to-snapshot \| --no-copy-tags-to-snapshot` | `CopyTagsToSnapshot` |
| `--db-instance-parameter-group-name` | `DBInstanceParameterGroupName` |
| `--domain` | `Domain` |
| `--domain-iam-role-name` | `DomainIAMRoleName` |
| `--enable-global-write-forwarding \| --no-enable-global-write-forwarding` | `EnableGlobalWriteForwarding` |
| `--enable-http-endpoint \| --no-enable-http-endpoint` | `EnableHttpEndpoint` |
| `--option-group-name` | `OptionGroupName` |
| `--port` | `Port` |
| `--scaling-configuration` | `ScalingConfiguration` |
| `--storage-type` | `StorageType` |
# Amazon RDS のマルチ AZ DB クラスターのエンジンバージョンのアップグレード
Amazon RDS では、マルチ AZ DB クラスターを最新の状態に維持するため、サポートされている各エンジンの新しいバージョンを提供します。このトピックでは、マルチ AZ DB クラスターを新しいバージョンにアップグレードするプロセスについて説明します。
マルチ AZ DB クラスターのアップグレードには、互換性のある新しいエンジンバージョンを選択し、潜在的なダウンタイムを計画する必要があります。このプロセスでは、マルチ AZ アーキテクチャのフェイルオーバー機能を活用することで、中断を最小限に抑えます。ベストプラクティスには、トラフィックの少ない期間のアップグレードの実行、非本番環境でのテスト、新しいバージョンとのアプリケーションの互換性の検証などがあります。
**Topics**
+ [マイナーバージョンのアップグレード](#multi-az-db-clusters-upgrade-minor)
+ [メジャーバージョンのアップグレード](#multi-az-db-clusters-upgrade-major)
+ [マルチ AZ DB クラスターのアップグレード](#multi-az-db-clusters-upgrade-process)
+ [マルチ AZ DB クラスターリードレプリカのアップグレード](#multi-az-db-clusters-upgrade-replicas)
+ [イベントによるマルチ AZ DB クラスターのアップグレードのモニタリング](#multi-az-db-clusters-upgrade-monitoring)
## マイナーバージョンのアップグレード
マイナーバージョンアップグレードには、既存のアプリケーションとの下位互換性がある変更のみが含まれます。マイナーバージョンアップグレードを開始すると、Amazon RDS は最初にリーダー DB インスタンスを一度に 1 つずつアップグレードします。その後、リーダー DB インスタンスの 1 つが新しいライター DB インスタンスに切り替わります。次に、Amazon RDS は、古いライターインスタンスをアップグレードします (リーダーインスタンスになります) 。
アップグレード中のダウンタイムは、リーダー DB インスタンスの 1 つが新しいライター DB インスタンスになるのにかかる時間に制限されます。このダウンタイムは、自動フェイルオーバーのように切り替わります。詳細については、「[Amazon RDS 用のマルチ AZ DB クラスターのフェイルオーバー](multi-az-db-clusters-concepts-failover.md)」を参照してください。マルチ AZ DB クラスターのレプリカの遅延は、ダウンタイムに影響する可能性があることに注意してください。詳細については、「[レプリカの遅延とマルチ AZ DB クラスター](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-replica-lag)」を参照してください。
RDS for PostgreSQL マルチ AZ DB クラスターのリードレプリカの場合、Amazon RDS はクラスターのメンバーであるインスタンスを一度に 1 つずつアップグレードします。リーダークラスターロールとライタークラスターのロールは、アップグレード中に切り替えられません。したがって、Amazon RDS がクラスターライターインスタンスをアップグレードしている間に、DB クラスターでダウンタイムが発生する可能性があります。
**注記**
マルチ AZ DB クラスターのマイナーバージョンアップグレードのダウンタイムは、通常 35 秒です。RDS Proxy と併用すると、ダウンタイムをさらに 1 秒以下に短縮できます。詳細については、「[Amazon RDS Proxy ](rds-proxy.md)」を参照してください。または、[ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/)、[PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/)、[AWS Advanced JDBC Wrapper Driver](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/) などのオープンソースデータベースプロキシを使用することもできます。
## メジャーバージョンのアップグレード
メジャーバージョンのアップグレードによって、既存のアプリケーションと互換性のない変更が導入されることがあります。
RDS for PostgreSQL マルチ AZ DB クラスターのメジャーバージョンのアップグレードを開始すると、Amazon RDS によってリーダーとライターのインスタンスが同時にアップグレードされます。したがって、アップグレードが完了するまで DB クラスターを使用できない場合があります。
RDS for MySQL マルチ AZ DB クラスターのメジャーバージョンアップグレードを開始すると、Amazon RDS はクラスターメンバーインスタンスを一度に 1 つずつアップグレードするため、レプリケーションはエンジンの下位バージョンから上位バージョンの順に行われます。エンジンのバージョンは構文と機能が異なる可能性があるため、メジャーバージョンのアップグレード中に、ワークロードがソースとターゲットのエンジンバージョンの間で互換性があるかを確認することが重要です。
**注記**
マイナーバージョンアップグレードと同様に、RDS for MySQL メジャーバージョンアップグレードのダウンタイムは通常 35 秒です。RDS Proxy と併用すると、ダウンタイムをさらに 1 秒以下に短縮できます。詳細については、「[Amazon RDS Proxy ](rds-proxy.md)」を参照してください。
## マルチ AZ DB クラスターのアップグレード
マルチ AZ DB クラスターのエンジンバージョンをアップグレードするプロセスは、DB インスタンスのエンジンバージョンをアップグレードするプロセスと同じです。手順については、「[DB インスタンスのエンジンバージョンのアップグレード](USER_UpgradeDBInstance.Upgrading.md)」を参照してください。唯一の違いは、AWS Command Line Interface (AWS CLI) を使用する場合、[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを実行して、`--db-cluster-identifier` パラメータ (および `--allow-major-version-upgrade` パラメータ) を指定するという点です。
メジャーバージョンおよびマイナーバージョンのアップグレードの詳細については、以下の DB エンジンに関するドキュメントを参照してください。
+ [RDS for PostgreSQL DB エンジンのアップグレード](USER_UpgradeDBInstance.PostgreSQL.md)
+ [RDS for MySQL DB エンジンのアップグレード](USER_UpgradeDBInstance.MySQL.md)
## マルチ AZ DB クラスターリードレプリカのアップグレード
Amazon RDS は、マルチ AZ DB クラスターのリードレプリカを自動的にアップグレードしません。*マイナー*バージョンアップグレードの場合、最初にすべてのリードレプリカを手動でアップグレードしてからクラスターをアップグレードする必要があります。そうしないと、アップグレードがブロックされます。クラスターの*メジャー*バージョンを実行すると、すべてのリードレプリカのレプリケーション状態が**終了**に変わります。アップグレードの完了後、リードレプリカを削除し、再作成する必要があります。詳細については、「[リードレプリケーションのモニタリング](USER_ReadRepl.Monitoring.md)」を参照してください。
## イベントによるマルチ AZ DB クラスターのアップグレードのモニタリング
マルチ AZ DB クラスターのエンジンバージョンをアップグレードすると、Amazon RDS はプロセスの各フェーズで特定のイベントを発行します。アップグレードの進行状況を追跡するには、これらのイベントを表示またはサブスクライブします。
RDS イベントの詳細については、「[Amazon RDS イベントのモニタリング](working-with-events.md)」を参照してください。
エンジンのアップグレード中に発生する特定の Amazon RDS イベントの詳細については、「[ Amazon RDS イベントカテゴリとイベントメッセージ](USER_Events.Messages.md)」を参照してください。
# Amazon RDS のマルチ AZ DB クラスターの名前の変更
マルチ AZ DB クラスターの名前を変更するには、AWS マネジメントコンソール、AWS CLI、`modify-db-cluster` コマンド、または Amazon RDS API `ModifyDBCluster` オペレーションを使用します。マルチ AZ DB クラスターの名前を変更すると、大きな影響があります。以下は、マルチ AZ DB クラスターの名前を変更する前の考慮事項の一覧です。
+ マルチ AZ DB クラスターの名前を変更すると、マルチ AZ DB クラスターのクラスターエンドポイントが変更されます。これらのエンドポイントは、マルチ AZ DB クラスターに割り当てた名前が含まれているために変更されます。古いエンドポイントから新しいエンドポイントにトラフィックをリダイレクトできます。マルチ AZ DB クラスターエンドポイントの詳細については、「[Amazon RDS のマルチ AZ DB クラスターへの接続](multi-az-db-clusters-concepts-connection-management.md)」を参照してください。
+ マルチ AZ DB クラスターの名前を変更すると、マルチ AZ DB クラスターが使用していた古い DNS 名は削除されますが、数分間キャッシュされたままになる場合があります。名前を変更したマルチ AZ DB クラスターの新しい DNS 名は、約 2 分後に有効になります。名前を変更したマルチ AZ DB クラスターは、新しい名前が有効になるまで使用できません。
+ クラスターの名前を変更する場合、既存のマルチ AZ DB クラスターの名前を使用することはできません。
+ マルチ AZ DB クラスターの名前に関連付けられたメトリクスとイベントは、DB クラスターの名前を再利用する場合も維持されます。
+ マルチ AZ DB クラスターのタグは、名前の変更にかかわらず、マルチ AZ DB クラスターに残ります。
+ DB クラスターのスナップショットは、名前を変更した マルチ AZ DB クラスターに保持されます。
**注記**
マルチ AZ DB クラスターは、クラウドで実行する独立したデータベース環境です。マルチ AZ DB クラスターは、複数のデータベースをホストすることができます。データベース名の変更の詳細については、DB エンジンのドキュメントを参照してください。
## 名前を変更して既存のマルチ AZ DB クラスターを置き換える
マルチ AZ DB クラスターの名前を変更する最も一般的なシナリオには、DB クラスターのスナップショットからのデータの復元や、ポイントインタイムリカバリ (PITR) の実行です。マルチ AZ DB クラスターの名前を変更することで、マルチ AZ DB クラスターを参照するアプリケーションコードを変更することなく、マルチ AZ DB クラスターを置き換えることができます。この場合、次のステップを完了します。
1. マルチ AZ DB クラスターに向かうトラフィックを停止します。マルチ AZ DB クラスターでデータベースにアクセスするトラフィックをリダイレクトするか、別の方法を選択してトラフィックのアクセスを回避します。
1. 既存のマルチ AZ DB クラスターの名前を変更します。
1. DB クラスターのスナップショットの復元またはポイントインタイムの復旧によって、新しいマルチ AZ DB クラスターを作成します。次に、新しいマルチ AZ DB クラスターに以前のマルチ AZ DB クラスターの名前を付けます。
古いマルチ AZ DB クラスターを削除した場合、古いマルチ AZ DB クラスターの不要な DB クラスターのスナップショットは、お客様によってすべて削除する必要があります。
## コンソール
**マルチ AZ DB クラスターの名前を変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**データベース**を選択します。
1. 名前を変更するマルチ AZ DB クラスターを選択します。
1. **Modify** を選択します。
1. **[Settings]** (設定) で､**[DB cluster identifier]** (DB クラスター識別子) に新しい名前を入力します。
1. **[Continue]** (続行) をクリックします。
1. 変更をすぐに反映させるには、[**Apply immediately**] を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、「[今すぐ変更を適用する](modify-multi-az-db-cluster.md#modify-multi-az-db-cluster-apply-immediately)」を参照してください。
1. 確認ページで、変更内容を確認します。正しい場合は、[**クラスターの変更**] を選択して変更を保存します。
または、**[Back]** (戻る) を選択して変更を編集するか、**[Cancel]** (キャンセル) を選択して変更を破棄します。
## AWS CLI
マルチ AZ DB クラスターの名前を変更するには、AWS CLI コマンドの [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) を使用します。マルチ AZ DB クラスターの新しい名前とともに、現在の `--db-cluster-identifier` 値および `--new-db-cluster-identifier` パラメータを指定します。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds modify-db-cluster \
2. --db-cluster-identifier DBClusterIdentifier \
3. --new-db-cluster-identifier NewDBClusterIdentifier
```
Windows の場合:
```
1. aws rds modify-db-cluster ^
2. --db-cluster-identifier DBClusterIdentifier ^
3. --new-db-cluster-identifier NewDBClusterIdentifier
```
## RDS API
マルチ AZ DB クラスターの名前を変更するには、以下のパラメータで、Amazon RDS API オペレーションの [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) を呼び出します。
+ `DBClusterIdentifier` - DB クラスターの既存の名前。
+ `NewDBClusterIdentifier` - DB クラスターの新しい名前。
# Amazon RDS のマルチ AZ DB クラスターとリーダー DB インスタンスの再起動
通常はメンテナンスのために、マルチAZ DB クラスターを再起動する必要がある場合があります。例えば、特定の変更を行う場合や DB クラスターに関連付けられた DB クラスターのパラメータグループを変更する場合、DB クラスターを再起動します。これを行うことで、変更が有効になります。
DB クラスターが、その関連付けられた DB クラスターパラメータグループに対する最新の変更を使用していない場合、AWS マネジメントコンソール は、DB クラスターパラメータグループのステータスを 「**再起動の保留中**」 と表示します。パラメータグループの [**再起動の保留中**] のステータスにより、次回のメンテナンスウィンドウで自動的に再起動されることはありません。パラメータの最新の変更を DB クラスターに適用するには、DB クラスターを手動で再起動します。パラメータグループの詳細については、「[マルチ AZ DB クラスターのパラメータグループ](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-parameter-groups)」を参照してください。
DB クラスターを再起動すると、データベースエンジンサービスが再起動されます。DB クラスターを再起動すると一時的に機能停止になります。その間、DB クラスターのステータスは 「**rebooting**」 に設定されます。
**available (利用可能)** 状態でない DB クラスターを再起動することはできません。データベースは、バックアップが進行中または、以前の要求による変更、メンテナンス時間のアクションなど、いくつかの理由で使用できない場合があります。
DB クラスターの再起動に要する時間は、クラッシュ回復プロセス、再起動時のデータベースのアクティビティ、および特定の DB クラスターの動作によって異なります。再起動時間を短くするには、再起動プロセス中のデータベースアクティビティをできる限り減らすことをお勧めします。データベースアクティビティを減らすと、未完了のトランザクションのロールバックアクティビティが減少します。
**重要**
マルチ AZ DB クラスターは、フェイルオーバーによる再起動をサポートしていません。マルチ AZ DB クラスターのライターインスタンスを再起動しても、その DB クラスター内のリーダー DB インスタンスには影響せず、フェイルオーバーは発生しません。リーダー DB インスタンスを再起動すると、フェイルオーバーは発生しません。マルチ AZ DB クラスターをフェイルオーバーするには、コンソールの**フェイルオーバー**を選択し、AWS CLIコマンド[https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html)、または API オペレーション[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html)をび出します。
## コンソール
**DB クラスターを再起動するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、「**データベース**」 を選択して、再起動したい マルチ AZ DBクラスターを選択します。
1. [**アクション**] で、[**再起動**] を選択します。
「**DB クラスターを再起動**」 ページが表示されます。
1. DB クラスターを再起動するには、「**Reboot**」 を選択します。
または、[**Cancel**] (キャンセル) を選択します。
## AWS CLI
AWS CLIを使用してマルチ AZ DB クラスターを再起動するには、[reboot-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-cluster.html)コマンドを呼び出します。
```
aws rds reboot-db-cluster --db-cluster-identifier mymultiazdbcluster
```
## RDS API
Amazon RDS API を使用してマルチ AZ DB クラスターを再起動するには、[リブートDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBCluster.html)オペレーションを呼び出します。
# Amazon RDS 用のマルチ AZ DB クラスターのフェイルオーバー
マルチ AZ DB クラスター内のライター DB インスタンスで計画的な機能停止または計画外の機能停止が発生した場合、Amazon RDS は別のアベイラビリティーゾーンのリーダー DB インスタンスに自動的にフェイルオーバーします。これにより、中断を最小限に抑えながら高可用性を確保できます。フェイルオーバーは、ハードウェア障害、ネットワークの問題、または手動リクエスト中に発生する可能性があります。このトピックでは、障害の自動検出、フェイルオーバー中のイベントのシーケンス、読み取りおよび書き込みオペレーションへの影響について説明します。また、フェイルオーバー時間をモニタリングして最小限に抑えるためのベストプラクティスも提供します。
フェイルオーバーが完了するまでにかかる時間は、データベースアクティビティや、ライターDB インスタンスが使用できなくなった時点の他の条件によって異なります。フェイルオーバーの時間は通常 35 秒未満です。フェイルオーバーは、両方のリーダー DB インスタンスが、失敗したライターからの未処理のトランザクションを適用すると完了します。フェイルオーバーが完了してから、新しいアベイラビリティーゾーンが RDS コンソールに反映されるまでさらに時間がかかる場合があります。
**Topics**
+ [自動フェイルオーバー](#multi-az-db-clusters-concepts-failover-automatic)
+ [マルチ AZ DB クラスターを手動でフェイルオーバーする](#multi-az-db-clusters-concepts-failover-manual)
+ [マルチ AZ DB クラスターがフェイルオーバーしたかどうかの判別](#multi-az-db-clusters-concepts-failover-determining)
+ [DNS 名参照用の JVM TTL の設定](#multi-az-db-clusters-concepts-failover-java-dns)
## 自動フェイルオーバー
Amazon RDS はフェイルオーバーを自動的に処理するため、管理者が操作しなくても可能な限りすみやかにデータベース操作を再開できます。フェイルオーバーするには、ライター DB インスタンスがリーダー DB インスタンスに自動的に切り替わります。
## マルチ AZ DB クラスターを手動でフェイルオーバーする
マルチ AZ DB クラスターを手動でフェイルオーバーすると、RDS は最初にプライマリ DB インスタンスを終了します。次に、内部モニタリングシステムがプライマリ DB インスタンスに異常があることを検出し、読み取り可能なレプリカ DB インスタンスを昇格させます。フェイルオーバーの時間は通常 35 秒未満です。
AWS マネジメントコンソール、AWS CLI、または RDS API を使用して、マルチ AZ DB クラスタを手動でフェイルオーバーできます。
### コンソール
**マルチ AZ DB クラスターを手動でフェイルオーバーするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**データベース**を選択します。
1. フェイルオーバーするマルチ AZ DB クラスターを選択します。
1. 「**アクション**」で、「**フェイルオーバー**」を選択します。
**[フェイルオーバー DB クラスター]** ページが表示されます。
1. **フェイルオーバー**を選択して、手動フェイルオーバーを確認します。
### AWS CLI
マルチ AZ DB クラスターを手動でフェイルオーバーするには、AWS CLIコマンド[フェイルオーバー db-クラスタ](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html)を使用します。
**Example**
```
1. aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster
```
### RDS API
マルチ AZ DB クラスターを手動でフェイルオーバーするには、Amazon RDS API [FailoverDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html)を呼び出し、`DBClusterIdentifier`を指定します。
## マルチ AZ DB クラスターがフェイルオーバーしたかどうかの判別
マルチ AZ DB クラスターがフェイルオーバーされたかどうかを判断するには、次を実行します。
+ フェイルオーバーがスタートされたことを電子メールまたはSMSで通知するようにDBイベントサブスクリプションを設定します。 イベントの詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
+ Amazon RDS コンソールまたは API オペレーションを使用して DB イベントを表示します。
+ Amazon RDS コンソール、AWS CLIおよび RDS API を使用して、マルチ AZ DB クラスターの現在の状態を表示します。
フェイルオーバーへの応答、復旧時間の短縮、Amazon RDS のその他のベストプラクティスについては、「[Amazon RDS のベストプラクティス](CHAP_BestPractices.md)」を参照してください。
## DNS 名参照用の JVM TTL の設定
フェイルオーバーメカニズムでは、リーダー DB インスタンスをポイントするように DB インスタンスのドメインネームシステム (DNS) レコードが自動的に変更されます。したがって、DB インスタンスへの既存の接続の再確立が必要になります。Java 仮想マシン (JVM) 環境では、Java DNS キャッシュ機構がどのように機能するかによって、JVM 設定の再構成が必要になる場合があります。
JVM は DNS 名参照をキャッシュします。JVM がホスト名を IP アドレスに変換するとき、*time-to-live* (TTL) と呼ばれる指定期間 IP アドレスをキャッシュします。
AWS リソースは、ときどき変更される DNS 名を使用するため、60 秒を超えない TTL 値で JVM を設定することをお勧めします。こうすることにより、リソースの IP アドレスが変更されたときに、アプリケーションは DNS に対して再度クエリを実行することで、リソースの新しい IP アドレスを取得して使用できます。
一部の Java 設定では JVM のデフォルトの TTL が設定されるため、JVM が再起動されるまで、DNS エントリが更新されることはありません。したがって、アプリケーションがまだ実行中に AWS リソースの IP アドレスが変更された場合、JVM を手動で再起動し、キャッシュされた IP 情報が更新されるまで、そのリソースを使用することはできません。この場合、キャッシュされた IP 情報が定期的に更新されるように JVM の TTL を設定することがきわめて重要です。
**注記**
デフォルト TTL は、JVM のバージョンと、セキュリティマネージャーがインストールされているかどうかに応じて変わります。多くの JVM はデフォルト TTL を 60 秒以下にしています。このような JVM を使用しており、セキュリティマネージャーを使用していない場合、このトピックの残り部分は無視してかまいません。Oracle のセキュリティマネージャーの詳細については、Oracle ドキュメントの 「[The Security Manager](https://docs.oracle.com/javase/tutorial/essential/environment/security.html)」を参照してください。
JVM の TTL を変更するには、[https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html](https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html) プロパティ値を設定します。ニーズに応じて、次の方法のいずれかを使用します。
+ JVM を使用するすべてのアプリケーションのプロパティ値をグローバルに設定するには、`networkaddress.cache.ttl` ファイルで `$JAVA_HOME/jre/lib/security/java.security` を設定します。
```
networkaddress.cache.ttl=60
```
+ アプリケーションに対してのみプロパティをローカルに設定するには、ネットワーク接続を確立する前に、アプリケーションの初期化コードで `networkaddress.cache.ttl` を設定します。
```
java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
```
# Amazon RDS のマルチ AZ DB クラスターを使用した PostgreSQL 論理レプリケーションの設定
マルチ AZ DB クラスターとの PostgreSQL 論理レプリケーションを使用することで、データベースインスタンス全体ではなく、個々のテーブルをレプリケートおよび同期できます。論理レプリケーションでは、パブリケーションおよびサブスクリプションモデルを使用して、ソースからの変更を 1 人または複数の受信者にレプリケートします。これは、PostgreSQL のログ先行書き込み (WAL) の変更レコードを使用することで動作します。詳細については、「[Amazon RDS for PostgreSQL の論理レプリケーションの実行](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)」を参照してください。
マルチ AZ DB クラスターのライター DB インスタンスに新しい論理レプリケーションスロットを作成すると、そのスロットはクラスター内の各リーダー DB インスタンスに非同期でコピーされます。リーダー DB インスタンスのスロットは、ライター DB インスタンスのスロットと継続的に同期されます。
論理レプリケーションは、RDS for PostgreSQL バージョン 14.8-R2 以降および 15.3-R2 以降を実行しているマルチ AZ DB クラスターでサポートされています。
**注記**
ネイティブの PostgreSQL 論理レプリケーション機能に加えて、RDS for PostgreSQL を実行しているマルチ AZ DB クラスターは `pglogical` 拡張機能もサポートしています。
PostgreSQL 論理レプリケーションの詳細については、PostgreSQL ドキュメントの「[論理レプリケーション](https://www.postgresql.org/docs/current/logical-replication.html)」を参照してください。
**Topics**
+ [前提条件](#multi-az-db-clusters-logical-replication-prereqs)
+ [論理レプリケーションの設定](#multi-az-db-clusters-logical-replication)
+ [制限と推奨事項](#multi-az-db-clusters-logical-replication-limitations)
## 前提条件
マルチ AZ DB クラスターの PostgreSQL 論理レプリケーションを設定するには、次の前提条件を満たす必要があります。
+ ユーザーアカウントは `rds_superuser` グループのメンバーであり、`rds_superuser` 権限を持っている必要があります。詳細については、「[PostgreSQL のロールとアクセス権限について](Appendix.PostgreSQL.CommonDBATasks.Roles.md)」を参照してください。
+ 次の手順で説明するパラメータ値を設定できるように、マルチ AZ DB クラスターをカスタム DB クラスターパラメータグループに関連付ける必要があります。詳細については、「[マルチ AZ DB クラスターの DB クラスターパラメータグループを使用する](USER_WorkingWithDBClusterParamGroups.md)」を参照してください。
## 論理レプリケーションの設定
マルチ AZ DB クラスターの論理レプリケーションを設定するには、関連する DB クラスターパラメータグループ内の特定のパラメータを有効にしてから、論理レプリケーションスロットを作成します。
**注記**
PostgreSQL バージョン 16 から、マルチ AZ DB クラスターのリーダー DB インスタンスを論理レプリケーションに使用できます。
**RDS for PostgreSQL マルチ AZ DB クラスターの論理レプリケーションをセットアップするには**
1. RDS for PostgreSQL マルチ AZ DB クラスターに関連付けられているカスタム DB クラスターパラメータグループを開きます。
1. **[パラメータ]** 検索フィールドで、`rds.logical_replication` 静的パラメータを探し、その値を `1` に設定します。このパラメータの変更により、WAL の生成量が増える可能性があるため、論理スロットを使用している場合にのみ有効にしてください。
1. この変更の一環として、次の DB クラスターパラメータを設定します。
+ `max_wal_senders`
+ `max_replication_slots`
+ `max_connections`
予想される使用状況に応じて、次のパラメータの値を変更しなければならない場合があります。ただし、多くの場合はデフォルト値で十分です。
+ `max_logical_replication_workers`
+ `max_sync_workers_per_subscription`
1. マルチ AZ DB クラスターを再起動して、パラメータ値を有効にします。手順については、「[Amazon RDS のマルチ AZ DB クラスターとリーダー DB インスタンスの再起動](multi-az-db-clusters-concepts-rebooting.md)」を参照してください。
1. [論理的なレプリケーションスロットの使用](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots) で説明されているように、マルチ AZ DB クラスターのライター DB インスタンスに論理レプリケーションスロットを作成します。このプロセスでは、デコードプラグインを指定する必要があります。現在、RDS for PostgreSQL は、PostgreSQL に付属する `test_decoding`、`wal2json`、および `pgoutput` プラグインをサポートしています。
スロットは、クラスター内の各リーダー DB インスタンスに非同期でコピーされます。
1. マルチ AZ DB クラスターのすべてのリーダー DB インスタンスのスロットの状態を確認します。そのためには、すべてのリーダー DB インスタンスの `pg_replication_slots` ビューを調べて、アプリケーションが論理的な変更を積極的に行っている間に `confirmed_flush_lsn` 状態が進行していることを確認します。
以下のコマンドは、リーダー DB インスタンスのレプリケーション状態を調べる方法を示しています。
```
% psql -h test-postgres-instance-2.abcdefabcdef.us-west-2.rds.amazonaws.com
postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
--------------+-----------+---------------------
logical_slot | logical | 32/D0001700
(1 row)
postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
--------------+-----------+---------------------
logical_slot | logical | 32/D8003628
(1 row)
% psql -h test-postgres-instance-3.abcdefabcdef.us-west-2.rds.amazonaws.com
postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
--------------+-----------+---------------------
logical_slot | logical | 32/D0001700
(1 row)
postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
--------------+-----------+---------------------
logical_slot | logical | 32/D8003628
(1 row)
```
レプリケーションタスクが完了したら、レプリケーションプロセスを停止し、レプリケーションスロットを削除して、論理レプリケーションをオフにします。論理レプリケーションをオフにするには、DB クラスターのパラメータグループを変更し、`rds.logical_replication` の値を `0` に戻します。クラスターを再起動して、パラメータの変更を有効にします。
## 制限と推奨事項
PostgreSQL 16 を実行するマルチ AZ DB クラスターでの論理レプリケーションの使用には、以下の制限事項と推奨事項があります。
+ 論理レプリケーションスロットを作成または削除するには、ライター DB インスタンのみを使用できます。例えば、`CREATE SUBSCRIPTION` コマンドでは、ホスト接続文字列にクラスターライターエンドポイントを使用する必要があります。
+ テーブルの同期または再同期中にクラスターライターエンドポイントを使用する必要があります。例えば、以下のコマンドを使用して、新しく追加されたテーブルを再同期できます。
```
Postgres=>ALTER SUBSCRIPTION subscription-name CONNECTION host=writer-endpoint
Postgres=>ALTER SUBSCRIPTION subscription-name REFRESH PUBLICATION
```
+ 論理レプリケーションにリーダー DB インスタンスを使用する前に、テーブルの同期が完了するのを待つ必要があります。テーブルの同期は、`[pg\$1subscription\$1rel](https://www.postgresql.org/docs/current/catalog-pg-subscription-rel.html)` カタログテーブルを使用して監視できます。テーブルの同期が完了すると、`srsubstate` 列が ready (`r`) に設定されます。
+ 最初のテーブル同期が完了したら、論理レプリケーション接続にインスタンスエンドポイントを使用することをお勧めします。次のコマンドは、いずれかのリーダー DB インスタンスにレプリケーションをオフロードすることで、ライター DB インスタンスの負荷を軽減します。
```
Postgres=>ALTER SUBSCRIPTION subscription-name CONNECTION host=reader-instance-endpoint
```
一度に複数の DB インスタンスで同じスロットを使用することはできません。2 つ以上のアプリケーションがクラスターの異なる DB インスタンスから論理的な変更をレプリケートしている場合、クラスターのフェイルオーバーやネットワークの問題により、一部の変更が失われる可能性があります。このような状況では、ホスト接続文字列で論理レプリケーションのインスタンスエンドポイントを使用できます。同じ設定を使用している他のアプリケーションには、次のエラーメッセージが表示されます。
```
replication slot slot_name is already active for PID x providing immediate feedback.
```
+ `pglogical` 拡張機能を使用している間は、クラスターライターエンドポイントのみを使用できます。拡張機能には、テーブルの同期中に未使用の論理レプリケーションスロットが作成される可能性がある既知の制限があります。古いレプリケーションスロットによって WAL ファイルが予約され、ディスク容量の問題を引き起こす可能性があります。
# Amazon RDS のマルチ AZ DB クラスターのリードレプリカの操作
DB クラスターのリードレプリカは、ソース DB インスタンスから作成する特殊なタイプのクラスターです。リードレプリカの作成後、プライマリ DB インスタンスに加えられた更新は、マルチ AZ DB クラスターのリードレプリカに非同期的にコピーされます。読み込みクエリをアプリケーションからリードレプリカにルーティングすることにより、プライマリ DB インスタンスの負荷を軽減できます。リードレプリカを使うと、単一 DB インスタンスのキャパシティ制約にとらわれることなく伸縮自在にスケールアウトし、読み込み負荷の高いデータベースワークロードに対応できます。
また、マルチ AZ DB クラスターから 1 つ以上の DB インスタンスのリードレプリカを作成できます。DB インスタンスのリードレプリカでは、余分な読み取りトラフィックをリードレプリカに送信することで、ソースマルチ AZ DB クラスターのコンピューティングまたは I/O のキャパシティを超えてスケーリングできます。現在、既存のマルチ AZ DB クラスターからマルチ AZ DB クラスターのリードレプリカを作成することはできません。
リードレプリカを使用してマルチ AZ DB クラスターに移行するか、マルチ AZ DB クラスターから DB インスタンスのリードレプリカを作成するかを選択する場合は、特定のユースケースとパフォーマンス要件を考慮してください。
**リードレプリカを使用してマルチ AZ DB クラスターに移行する**
このアプローチは、ダウンタイムを最小限に抑えながらデータベースの可用性と耐久性を向上させる必要がある場合に最適です。リードレプリカを使用してマルチ AZ DB クラスターに移行することで、継続的なオペレーションとデータ整合性を確保できます。この方法は、可用性を維持し、ライブワークロードへの影響を減らすことが重要な本番環境に特に役立ちます。
**マルチ AZ DB クラスターからの DB インスタンスリードレプリカの作成**
この方法は、読み取りオペレーションをスケールしたり、プライマリデータベースインスタンスから読み取りトラフィックをオフロードしたりする場合に適しています。既存のマルチ AZ DB クラスターからリードレプリカを作成することで、読み取り負荷の高いワークロードを分散させ、プライマリインスタンスの安定性に影響を与えることなくパフォーマンスを向上させることができます。
適切なアプローチの選択は、高い可用性と耐久性を確保するか、読み取りパフォーマンスをスケーリングするかによって異なります。ワークロードの特性と運用要件を評価して、情報に基づいた意思決定を行います。
**Topics**
+ [リードレプリカを使用してマルチ AZ DB クラスターに移行する](multi-az-db-clusters-migrating-to-with-read-replica.md)
+ [マルチ AZ DB クラスターからの DB インスタンスリードレプリカの作成](multi-az-db-clusters-create-instance-read-replica.md)
# リードレプリカを使用してマルチ AZ DB クラスターに移行する
シングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターデプロイに少ないダウンタイムで移行するには、マルチ AZ DB クラスターリードレプリカを作成します。ソースとして、シングル AZ デプロイの DB インスタンス、またはマルチ AZ DB インスタンスデプロイのプライマリ DB インスタンスを指定します。DB インスタンスは、マルチ AZ DB クラスターへの移行時に書き込みトランザクションを処理できます。
以下は、マルチ AZ DB クラスターのリードレプリカを作成する前の考慮事項です。
+ ソース DB インスタンスは、マルチ AZ DB クラスターをサポートするバージョンである必要があります。詳細については、「[Amazon RDS のマルチ AZ DB クラスターでサポートされているリージョンと DB エンジン](Concepts.RDS_Fea_Regions_DB-eng.Feature.MultiAZDBClusters.md)」を参照してください。
+ マルチ AZ DB クラスターのリードレプリカは、ソースと同じメジャーバージョンで、同じかそれ以上のマイナーバージョンでなければなりません。
+ バックアップ保持期間を 0 以外の値に設定することで、ソース DB インスタンスで自動バックアップを有効にする必要があります。
+ ソース DB インスタンスに割り当てられるストレージは 100 GiB 以上でなければなりません。
+ RDS for MySQL では、`gtid-mode` と `enforce_gtid_consistency` パラメータの両方は、ソース DB インスタンスの `ON` に設定する必要があります。デフォルトのパラメータグループではなく、カスタムパラメータグループを使用する必要があります。詳細については、「[Amazon RDS DB インスタンスの DB パラメータグループ](USER_WorkingWithDBInstanceParamGroups.md)」を参照してください。
+ アクティブな長時間実行トランザクションの場合、リードレプリカの作成プロセスに時間がかかることがあります。長時間実行トランザクションが完了してから、リードレプリカを作成することをお勧めします。
+ マルチ AZ DB クラスターのリードレプリカのソース DB インスタンスを削除した場合、リードレプリカはスタンドアロンのマルチ AZ DB クラスターに昇格されます。
## マルチ AZ DB クラスターのリードレプリカの作成と昇格
マルチAZ DB クラスターのリードレプリカの作成と昇格には、AWS マネジメントコンソール、AWS CLI、または RDS API を使用します。
**注記**
ソース DB インスタンスの Amazon VPC に基づいて、すべてのリードレプリカを同じ仮想プライベートクラウド (VPC) に作成することを強くお勧めします。
リードレプリカをソース DB インスタンスとは異なる VPC に作成すると、クラスレスドメイン間ルーティング (CIDR) の範囲がレプリカと Amazon RDS システムとの間で重複する可能性があります。CIDR が重複すると、レプリカが不安定になり、レプリカに接続するアプリケーションに悪影響を及ぼす可能性があります。リードレプリカの作成時にエラーが発生した場合は、別のターゲット DB サブネットグループを選択します。詳細については、「[VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md)」を参照してください。
### コンソール
リードレプリカを使用してシングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターに移行するには、AWS マネジメントコンソール を使用して次の手順を実行します。
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. マルチ AZ DB クラスターのリードレプリカを作成します。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. リードレプリカのソースとして使用する DB インスタンスを選択します。
1. [**アクション**] で [**リードレプリカの作成**] を選択します。
1. **[Availability and durability]** (可用性と耐久性) で、**[Multi-AZ DB cluster]** (マルチ AZ DB クラスター) を選択します。
1. **DB インスタンス識別子**に、リードレプリカの名前を入力します。
1. 残りのセクションで、DB クラスター設定を指定します。設定の詳細については、「[マルチ AZ DB クラスターを作成するための設定](create-multi-az-db-cluster.md#create-multi-az-db-cluster-settings)」を参照してください。
1. [**Create read replica**] を選択します。
1. 準備ができたら、リードレプリカをスタンドアロンのマルチ AZ DB クラスターに昇格します。
1. トランザクションがソース DB インスタンスに書き込まれるのを停止して、すべての更新がリードレプリカに反映されるまで待ちます。
データベースの更新は、プライマイ DB インスタンスで行われた後にリードレプリカで行われます。このレプリケーションのラグは大きく異なる可能性があります。`ReplicaLag` メトリクスを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。レプリカラグの詳細については、「[リードレプリケーションのモニタリング](USER_ReadRepl.Monitoring.md)」を参照してください。
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールで、[**Databases (データベース)**] を選択します。
[**Databases (データベース)**] ペインが表示されます。各リードレプリカには､[**Role (ロール)**] 列に [**Replica (レプリカ)**] があります｡
1. 昇格するマルチ AZ DBクラスターのリードレプリカを選択します。
1. [**アクション**] で、[**Promote (昇格)**] を選択します。
1. **[Promote read replica]** (リードレプリカの昇格) ページで、新しく昇格されたマルチ AZ DB クラスターのバックアップ保持期間とバックアップウィンドウを入力します。
1. 希望通りの設定になったら、**[Promote read replica]** (リードレプリカの昇格) を選択します。
1. 昇格されたマルチ AZ DB クラスターのステータスが `Available` になるまで待ちます。
1. 昇格されたマルチ AZ DB クラスターを使用するようにアプリケーションに指示します。
必要に応じて、シングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイが不要になった場合は削除します。手順については、[DB インスタンスを削除する](USER_DeleteInstance.md) を参照してください。
### AWS CLI
リードレプリカを使用してシングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターに移行するには、AWS CLI を使用して次の手順を実行します。
1. マルチ AZ DB クラスターのリードレプリカを作成します。
ソース DB インスタンスからリードレプリカを作成するには、AWS CLI コマンド [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) を使用します。`--replication-source-identifier` として、ソース DB インスタンスの Amazon リソースネーム (ARN) を指定します。
Linux、macOS、Unix の場合:
```
aws rds create-db-cluster \
--db-cluster-identifier mymultiazdbcluster \
--replication-source-identifier arn:aws:rds:us-east-2:123456789012:db:mydbinstance
--engine postgres \
--db-cluster-instance-class db.m5d.large \
--storage-type io1 \
--iops 1000 \
--db-subnet-group-name defaultvpc \
--backup-retention-period 1
```
Windows の場合:
```
aws rds create-db-cluster ^
--db-cluster-identifier mymultiazdbcluster ^
--replication-source-identifier arn:aws:rds:us-east-2:123456789012:db:mydbinstance
--engine postgres ^
--db-cluster-instance-class db.m5d.large ^
--storage-type io1 ^
--iops 1000 ^
--db-subnet-group-name defaultvpc ^
--backup-retention-period 1
```
1. トランザクションがソース DB インスタンスに書き込まれるのを停止して、すべての更新がリードレプリカに反映されるまで待ちます。
データベースの更新は、プライマイ DB インスタンスで行われた後にリードレプリカで行われます。このレプリケーションのラグは大きく異なる可能性があります。`Replica Lag` メトリクスを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。レプリカラグの詳細については、「[リードレプリケーションのモニタリング](USER_ReadRepl.Monitoring.md)」を参照してください。
1. 準備ができたら、リードレプリカをスタンドアロンのマルチ AZ DB クラスターに昇格します。
マルチ AZ DB クラスターのリードレプリカを昇格するには、AWS CLI コマンド [https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) を使用します。`--db-cluster-identifier` として、マルチ AZ DB クラスターリードレプリカの ID を指定します。
```
aws rds promote-read-replica-db-cluster --db-cluster-identifier mymultiazdbcluster
```
1. 昇格されたマルチ AZ DB クラスターのステータスが `Available` になるまで待ちます。
1. 昇格されたマルチ AZ DB クラスターを使用するようにアプリケーションに指示します。
必要に応じて、シングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイが不要になった場合は削除します。手順については、[DB インスタンスを削除する](USER_DeleteInstance.md) を参照してください。
### RDS API
リードレプリカを使用してシングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターに移行するには、RDS AAPI を使用して次の手順を実行します。
1. マルチ AZ DB クラスターのリードレプリカを作成します。
マルチ AZ DB クラスターのリードレプリカを作成するには、必須パラメータ `DBClusterIdentifier` を指定して、[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) オペレーションを使用します。`ReplicationSourceIdentifier` として、ソース DB インスタンスの Amazon リソースネーム (ARN) を指定します。
1. トランザクションがソース DB インスタンスに書き込まれるのを停止して、すべての更新がリードレプリカに反映されるまで待ちます。
データベースの更新は、プライマイ DB インスタンスで行われた後にリードレプリカで行われます。このレプリケーションのラグは大きく異なる可能性があります。`Replica Lag` メトリクスを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。レプリカラグの詳細については、「[リードレプリケーションのモニタリング](USER_ReadRepl.Monitoring.md)」を参照してください。
1. 準備ができたら、リードレプリカをスタンドアロンのマルチ AZ DB クラスターに昇格します。
マルチ AZ DB クラスターのリードレプリカを昇格するには、必須パラメータ `DBClusterIdentifier` を指定して、[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html) オペレーションを使用します。マルチ AZ DB クラスターリードレプリカの ID を指定します。
1. 昇格されたマルチ AZ DB クラスターのステータスが `Available` になるまで待ちます。
1. 昇格されたマルチ AZ DB クラスターを使用するようにアプリケーションに指示します。
必要に応じて、シングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイが不要になった場合は削除します。手順については、[DB インスタンスを削除する](USER_DeleteInstance.md) を参照してください。
## マルチ AZ DB クラスターのリードレプリカの作成に関する制限事項
次の制限は、シングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイから マルチ AZ DB クラスターのリードレプリカを作成する際に適用されます。
+ ソース DB インスタンスを所有する AWS アカウント とは異なる AWS アカウント では、マルチ AZ DB クラスターのリードレプリカを作成することはできません。
+ マルチ AZ DB クラスターのリードレプリカは、ソース DB インスタンスとは異なる AWS リージョン で作成することはできません。
+ マルチ AZ DB クラスターのリードレプリカを指定の時点に復元することはできません。
+ ストレージ暗号化は、ソース DB インスタンスとマルチ AZ DB クラスターで同じ設定にする必要があります。
+ ソース DB インスタンスが暗号化されている場合、マルチ AZ DB クラスターのリードレプリカは同じ KMS キーを使用して暗号化する必要があります。
+ ソース DB インスタンスが汎用 SSD (gp3) ストレージを使用しており、割り当てられたストレージが 400 GiB 未満の場合、マルチ AZ DB クラスターのリードレプリカのプロビジョンド IOPS は変更できません。
+ ソース DB インスタンスでマイナーバージョンアップグレードを実行するには、まず、マルチ AZ DB クラスターリードレプリカでマイナーバージョンアップグレードを実行する必要があります。
+ RDS for PostgreSQL マルチ AZ DB クラスターのリードレプリカでマイナーバージョンアップグレードを実行すると、アップグレード後にリーダー DB インスタンスがライター DB インスタンスに切り替えられません。したがって、Amazon RDS がライターインスタンスをアップグレードしている間に、DB クラスターでダウンタイムが発生する可能性があります。
+ マルチ AZ DB クラスターのリードレプリカでメジャーバージョンアップグレードを実行することはできません。
+ マルチ AZ DB クラスターリードレプリカのソース DB インスタンスでメジャーバージョンアップグレードを実行できますが、リードレプリカへのレプリケーションは停止し、再開できません。
+ マルチ AZ DB クラスターのリードレプリカは、カスケードリードレプリカをサポートしていません。
+ RDS for PostgreSQL では、マルチ AZ DB クラスターのリードレプリカはフェイルオーバーできません。
# マルチ AZ DB クラスターからの DB インスタンスリードレプリカの作成
クラスターのコンピューティングまたは I/O のキャパシティを超えてスケーリングするために、マルチ AZ DB クラスターから DB インスタンスのリードレプリカを作成できます。このような過度の読み込みトラフィックを 1 つまたは複数の DB インスタンスのリードレプリカに割り振ることができます。また、リードレプリカを使用して、マルチ AZ DB クラスターから DB インスタンスに移行することもできます。
リードレプリカを作成するには、マルチ AZ DB クラスターをレプリケーションソースとして指定します。ライターインスタンスではなく、マルチ AZ DB クラスターのリーダーインスタンスのいずれかが常にレプリケーションのソースです。この条件により、フェイルオーバーが発生した場合でも、レプリカは常にソースクラスターと同期されます。
**Topics**
+ [リーダー DB インスタンスと DB インスタンスのリードレプリカの比較](#multi-az-db-clusters-readerdb-vs-dbrr)
+ [考慮事項](#multi-az-db-clusters-instance-read-replica-considerations)
+ [DB インスタンスのリードレプリカの作成](#multi-az-db-clusters-instance-read-replica-create)
+ [DB インスタンスのリードレプリカの昇格](#multi-az-db-clusters-promote-instance-read-replica)
+ [マルチ AZ DB クラスターからの DB インスタンスリードレプリカの作成に関する制限事項](#multi-az-db-clusters-create-instance-read-replica-limitations)
## リーダー DB インスタンスと DB インスタンスのリードレプリカの比較
マルチ AZ DB クラスターの *DB インスタンスのリードレプリカ*は、マルチ AZ DB クラスターの*リーダー DB インスタンス*と次の点で異なります。
+ リーダー DB インスタンスは自動フェイルオーバーターゲットとして機能しますが、DB インスタンスのリードレプリカにその機能はありません。
+ リーダー DB インスタンスは、変更をコミットする前に、ライター DB インスタンスからの変更を確認する必要があります。ただし、DB インスタンスのリードレプリカの場合、更新は確認を必要とせずにリードレプリカに非同期的にコピーされます。
+ リーダー DB インスタンスは、マルチ AZ DB クラスターのライター DB インスタンスと常に同じインスタンスクラス、ストレージタイプ、およびエンジンバージョンを共有します。ただし、DB インスタンスのリードレプリカは、必ずしもソースクラスターと同じ設定を共有する必要はありません。
+ DB インスタンスのリードレプリカをスタンドアロン DB インスタンスに昇格させることができます。マルチ AZ DB クラスターの DB インスタンスをスタンドアロンインスタンスに昇格することはできません。
+ リーダーエンドポイントは、マルチ AZ DB クラスターのリーダー DB インスタンスにのみリクエストをルーティングします。DB インスタンスのリードレプリカにリクエストをルーティングすることはありません。
リーダーおよびライター DB インスタンスの詳細については、「[マルチ AZ DB クラスターアーキテクチャ](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-overview)」を参照してください。
## 考慮事項
マルチ AZ DB クラスターから DB インスタンスのリードレプリカを作成する前に以下を検討してください。
+ DB インスタンスのリードレプリカを作成するとき、ソースクラスターと同じメジャーバージョンで、同じかそれ以上のマイナーバージョンでなければなりません。作成後、オプションでリードレプリカをソースクラスターよりも上位のマイナーバージョンにアップグレードできます。
+ DB インスタンスのリードレプリカを作成する場合、割り当てられるストレージは、ソースのマルチ AZ DB クラスターに割り当てられたストレージと同じである必要があります。割り当てられたストレージは、リードレプリカの作成後に変更できます。
+ RDS for MySQL の場合、ソースマルチ AZ DB クラスターでは、`gtid-mode` パラメータを `ON` に設定する必要があります。詳細については、「[マルチ AZ DB クラスターの DB クラスターパラメータグループを使用する](USER_WorkingWithDBClusterParamGroups.md)」を参照してください。
+ アクティブな長時間実行トランザクションの場合、リードレプリカの作成プロセスに時間がかかることがあります。長時間実行トランザクションが完了してから、リードレプリカを作成することをお勧めします。
+ DB インスタンスのリードレプリカのソースマルチ AZ DB インスタンスを削除した場合、書き込み先のリードレプリカはスタンドアロン DB インスタンスに昇格されます。
## DB インスタンスのリードレプリカの作成
AWS マネジメントコンソール、AWS CLI、または RDS API を使用して、マルチ AZ DB クラスターから DB インスタンスのリードレプリカを作成できます。
**注記**
ソースマルチ AZ DB クラスターの Amazon VPC に基づいて、すべてのリードレプリカを同じ仮想プライベートクラウド (VPC) に作成することを強くお勧めします。
リードレプリカをソースマルチ AZ DB クラスターとは異なる VPC に作成すると、Classless Inter-Domain Routing (CIDR) の範囲がレプリカと RDS システムとの間で重複する可能性があります。CIDR が重複すると、レプリカが不安定になり、レプリカに接続するアプリケーションに悪影響を及ぼす可能性があります。リードレプリカの作成時にエラーが発生した場合は、別のターゲット DB サブネットグループを選択します。詳細については、「[VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md)」を参照してください。
### コンソール
マルチ AZ DB インスタンスリードレプリカを作成するには、AWS マネジメントコンソール を使用して次のステップを実行します。
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**データベース** を選択します。
1. リードレプリカのソースとして使用するマルチ AZ DB クラスターを選択します。
1. [**アクション**] で [**リードレプリカの作成**] を選択します。
1. **レプリカソース**に、正しいマルチ AZ DB クラスターが選択されていることを確認してください。
1. **DB 識別子**に、リードレプリカの名前を入力します。
1. 残りのセクションで、DB インスタンス設定を指定します。設定の詳細については、「[DB インスタンスの設定](USER_CreateDBInstance.Settings.md)」を参照してください。
**注記**
DB インスタンスのリードレプリカに割り当てられたストレージは、ソースマルチ AZ DB クラスターに割り当てられたストレージと同じである必要があります。
1. [**Create read replica**] を選択します。
### AWS CLI
マルチ AZ DB クラスターから DB インスタンスのリードレプリカを作成するには、AWS CLI コマンド [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html) を使用します。`--source-db-cluster-identifier` には、マルチ AZ DB クラスターの識別子を指定します。
Linux、macOS、Unix の場合:
```
aws rds create-db-instance-read-replica \
--db-instance-identifier myreadreplica \
--source-db-cluster-identifier mymultiazdbcluster
```
Windows の場合:
```
aws rds create-db-instance-read-replica ^
--db-instance-identifier myreadreplica ^
--source-db-cluster-identifier mymultiazdbcluster
```
### RDS API
マルチ AZ DB クラスターから DB インスタンスのリードレプリカを作成するには、[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html) オペレーションを使用します。
## DB インスタンスのリードレプリカの昇格
DB インスタンスのリードレプリカが不要になった場合は、スタンドアロン DB インスタンスに昇格できます。リードレプリカを昇格させると、使用可能になる前に DB インスタンスが再起動されます。手順については、「[リードレプリカをスタンドアロン DB インスタンスに昇格させる](USER_ReadRepl.Promote.md)」を参照してください。
リードレプリカを使用してシングル AZ DB クラスターデプロイをシングル AZ またはマルチ AZ DB インスタンスデプロイに移行している場合は、ソース DB クラスターに書き込まれるトランザクションを必ず停止してください。次に、リードレプリカにすべての更新が行われるまで待ちます。データベースの更新は、マルチ AZ DB クラスターのリーダー DB インスタンスのいずれかで行われた後にリードレプリカで実行されます。このレプリケーションのラグは大きく異なる可能性があります。`ReplicaLag` メトリクスを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。レプリカラグの詳細については、「[リードレプリケーションのモニタリング](USER_ReadRepl.Monitoring.md)」を参照してください。
リードレプリカを昇格させたら、昇格した DB インスタンスのステータスが `Available` になるのを待ってから、昇格した DB インスタンスを使用するようアプリケーションに指示します。必要に応じて、マルチ AZ DB クラスターデプロイが不要になった場合は削除することもできます。手順については、「[Amazon RDS 用のマルチ AZ DB クラスターの削除](USER_DeleteMultiAZDBCluster.Deleting.md)」を参照してください。
## マルチ AZ DB クラスターからの DB インスタンスリードレプリカの作成に関する制限事項
次の制限事項は、マルチ AZ DB インスタンスデプロイから DB インスタンスのリードレプリカを作成する際に適用されます。
+ ソースマルチ AZ DB クラスターを所有する AWS アカウント とは異なる AWS アカウント では、 DB インスタンスのリードレプリカを作成することはできません。
+ ソースマルチ AZ DB クラスターとは異なる AWS リージョン で DB インスタンスのリードレプリカを作成することはできません。
+ DB インスタンスのリードレプリカを指定の時点に復元することはできません。
+ ストレージ暗号化は、ソースマルチ AZ DB クラスターと DB インスタンスのリードレプリカで同じ設定にする必要があります。
+ ソースマルチ AZ DB クラスターが暗号化されている場合、DB インスタンスのリードレプリカは同じ KMS キーを使用して暗号化する必要があります。
+ ソースマルチ AZ DB クラスターでマイナーバージョンアップグレードを実行するには、まず、DB インスタンスのリードレプリカでマイナーバージョンアップグレードを実行する必要があります。
+ DB インスタンスのリードレプリカは、カスケードリードレプリカをサポートしていません。
+ RDS for PostgreSQL の場合、DB インスタンスのリードレプリカを作成するには、ソースのマルチ AZ DB クラスターは PostgreSQL バージョン 13.11、14.8、または 15.2.R2 以降を実行している必要があります。
+ DB インスタンスリードレプリカのマルチ AZ DB クラスターでメジャーバージョンアップグレードを実行できますが、リードレプリカへのレプリケーションが停止し、再開できません。
# Amazon RDS のマルチ AZ DB クラスターからの外部レプリケーションの設定
マルチ AZ DB クラスターと Amazon RDS の外部にあるデータベースとの間のレプリケーションを設定できます。
外部レプリケーションにより、マルチ AZ DB クラスターは、オンプレミスまたは別のクラウド環境の RDS DB インスタンスと外部データベース間でデータをレプリケートできます。これは、ディザスタリカバリ、データ移行、および異なる場所のシステム間の整合性の維持に役立ちます。このセクションでは、レプリケーション設定の前提条件、プロセスの設定方法、レプリケーションのレイテンシー、帯域幅、さまざまなデータベースエンジンとの互換性などの重要な考慮事項について説明します。
## RDS for MySQL
RDS for MySQL マルチ AZ DB クラスターの外部レプリケーションを設定するには、Amazon RDS がバイナリログファイルを削除する前に、変更がレプリカに適用されるように、クラスター内の DB インスタンスにバイナリログファイルを十分長く保持する必要があります。そのためには、`mysql.rds_set_configuration` ストアドプロシージャを呼び出し、`binlog retention hours` パラメータを指定することによって、バイナリログの保持を設定します。詳細については、「[バイナリログの保持時間](mysql-stored-proc-configuring.md#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)」を参照してください。
`binlog retention hours` のデフォルト値は `NULL` です。つまり、バイナリログは保持されません (0 時間)。マルチ AZ DB クラスターの外部レプリケーションを設定する場合は、 パラメータを `NULL` 以外の値に設定する必要があります。
マルチ AZ DB クラスターのライター DB インスタンスからのみバイナリログ保持を設定でき、設定はすべてのリーダー DB インスタンスに非同期的に伝播されます。
さらに、外部レプリカで GTID ベースのレプリケーションを有効にすることを強くお勧めします。その後、いずれかの DB インスタンスに障害が発生した場合は、クラスター内の別の正常な DB インスタンスからのレプリケーションを再開できます。詳細については、MySQL ドキュメントの「[グローバルトランザクション識別子を使用したレプリケーション](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids.html)」を参照してください。
## RDS for PostgreSQL
RDS for PostgreSQL マルチ AZ DB クラスターの外部レプリケーションをセットアップするには、論理レプリケーションを有効にする必要があります。手順については、「[Amazon RDS のマルチ AZ DB クラスターを使用した PostgreSQL 論理レプリケーションの設定](USER_MultiAZDBCluster_LogicalRepl.md)」を参照してください。
# Amazon RDS 用のマルチ AZ DB クラスターの削除
AWS マネジメントコンソール、AWS CLI、または RDS API を使用して、DB マルチ AZ DB クラスターを削除できます。
マルチ AZ DB クラスターの削除に要する時間は、次の要因によって異なります。
+ バックアップ保持期間 (削除するバックアップの数）。
+ 削除されるデータの量。
+ 最終スナップショットを作成するかどうか。
マルチ AZ DB クラスターを削除する前に、削除保護を無効にする必要があります。詳細については、「[DB インスタンスの削除の前提条件](USER_DeleteInstance.md#USER_DeleteInstance.DeletionProtection)」を参照してください。DB クラスターの設定を変更することで、削除保護を無効にできます。詳細については、「[Amazon RDS のマルチ AZ DB クラスターの変更](modify-multi-az-db-cluster.md)」を参照してください。
## コンソール
**マルチ AZ DB クラスターを削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. ナビゲーションペインで、「**データベース**」 を選択して、削除したいマルチ AZ DB クラスターを選択します。
1. **[アクション]** で、**[削除]** を選択します。
1. マルチ AZ DB クラスターの最終 DB スナップショットを作成するには、「**最終スナップショットを作成しますか**」 を選択します。
最終スナップショットを作成する場合は、**[Final snapshot name]** (最終スナップショット名)を入力します。
1. 自動バックアップを保持するには、**[Retain automated backups]** (自動バックアップの保持) を選択します。
1. ボックスに「**delete me**」と入力します。
1. [**削除**] を選択します。
## AWS CLI
AWS CLIを使用して マルチAZ DB クラスターを削除するには、以下のオプションを使用して [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html) コマンドを呼び出します。
+ `--db-cluster-identifier`
+ `--final-db-snapshot-identifier`、または `--skip-final-snapshot`
**Example 最終スナップショットで**
Linux、macOS、Unix の場合:
```
aws rds delete-db-cluster \
--db-cluster-identifier mymultiazdbcluster \
--final-db-snapshot-identifier mymultiazdbclusterfinalsnapshot
```
Windows の場合:
```
aws rds delete-db-cluster ^
--db-cluster-identifier mymultiazdbcluster ^
--final-db-snapshot-identifier mymultiazdbclusterfinalsnapshot
```
**Example 最終スナップショットなし**
Linux、macOS、Unix の場合:
```
aws rds delete-db-cluster \
--db-cluster-identifier mymultiazdbcluster \
--skip-final-snapshot
```
Windows の場合:
```
aws rds delete-db-cluster ^
--db-cluster-identifier mymultiazdbcluster ^
--skip-final-snapshot
```
## RDS API
Amazon RDS API を使用して マルチ AZ DB インスタンスを削除するには、以下のパラメータを指定して[DeleteDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html) オペレーションを呼び出します。
+ `DBClusterIdentifier`
+ `FinalDBSnapshotIdentifier`、または `SkipFinalSnapshot`
# Amazon RDS のマルチ AZ DB クラスターの制限事項
マルチ AZ DB クラスターには、3 つの別々のアベイラビリティーゾーンに 1 つのライター DB インスタンスと 2 つのリーダー DB インスタンスがあります。マルチ AZ DB クラスターは、マルチ AZ 配置と比較して、高可用性、読み取りワークロードの容量の増加、および低レイテンシーを提供します。マルチ AZ DB の配置の詳細については、「[Amazon RDS のマルチ AZ DB クラスターデプロイ](multi-az-db-clusters-concepts.md)」を参照してください。
マルチ AZ DB クラスターには、次の制約事項が適用されます。
+ マルチ AZ DB クラスターでは、次の機能はサポートされていません。
+ IPv6 接続（デュアルスタックモード）
+ クロスリージョン自動バックアップ
+ Kerberos 認証
+ ポートの変更。別の方法として、マルチ AZ DB クラスターを特定の時点に復元し、別のポートを指定することもできます。
+ オプショングループ
+ 削除されたクラスターのポイントインタイムリカバリ (PITR)
+ 割り当てられる最大ストレージを設定することによるストレージの自動スケーリング。または、ストレージを手動でスケールすることもできます。
+ マルチ AZ DB クラスターの停止と起動
+ マルチ AZ DB クラスターのスナップショットをコピーする
+ 暗号化されていないマルチ AZ DB クラスターを暗号化する
+ RDS for MySQL マルチ AZ DB クラスターでは、次のシステムストアドプロシージャのみがサポートされています。
+ `mysql.rds_rotate_general_log`
+ `mysql.rds_rotate_slow_log`
+ `mysql.rds_show_configuration`
+ `mysql.rds_set_external_master_with_auto_position`
+ `mysql.rds_set_configuration`
+ RDS for PostgreSQL マルチ AZ DB クラスターは、`aws_s3` と `pg_transport` の PostgreSQL の拡張機能をサポートしていません。
+ RDS for PostgreSQL マルチ AZ DB クラスターは、アウトバウンドネットワークアクセスでのカスタム DNS サーバーの使用をサポートしていません。