Aurora 用 Amazon RDS ブルー/グリーンデプロイの概要 - Amazon Aurora
利点ワークフローアクセスの承認考慮事項ベストプラクティスリージョンとバージョンの可用性制限事項

Aurora 用 Amazon RDS ブルー/グリーンデプロイの概要

Amazon RDS ブルー/グリーンデプロイを使用すると、本番環境に実装する前に、データベースに変更を加えてテストできます。ブルー/グリーンのデプロイは、本稼働環境をコピーするステージング環境を作成します。ブルー/グリーンデプロイでは、ブルー環境が現在の本稼働環境です。グリーン環境はステージング環境です。ステージング環境は、論理レプリケーションを使用して現在の本稼働環境と同期したままになります。

本稼働環境のワークロードに影響を与えずに、グリーン環境の Aurora DB クラスターに変更を加えることができます。例えば、DB エンジンのメジャーまたはマイナーバージョンのアップグレード、、またはデータベースパラメータの変更をステージング環境で行うことができます。グリーン環境での変化を徹底的にテストできます。準備ができたら、環境を切り替えてグリーン環境を新しい本稼働環境にプロモートできます。切り替えには通常 1 分もかからず、データが失われることはなく、アプリケーションを変更する必要もありません。

グリーン環境は本稼働環境のトポロジのコピーであるため、DB クラスターとそのすべての DB インスタンスはデプロイにコピーされます。グリーン環境には、DB クラスタースナップショット、パフォーマンスインサイト、拡張モニタリング、Aurora Serverless v2 など、DB クラスターで使用される機能も含まれています。

注記

ブルー/グリーンデプロイは、Aurora MySQL と Aurora PostgreSQL でサポートされています。Amazon RDS の可用性については、「Amazon RDS ユーザーガイド」の「データベースの更新のために Amazon RDS ブルー/グリーンデプロイを使用する」を参照してください。

Amazon RDS ブルー/グリーンデプロイを使用する利点

Amazon RDS ブルー/グリーンデプロイを使用すると、セキュリティパッチを最新の状態に保ち、データベースのパフォーマンスを向上させ、短い予測可能なダウンタイムで新しいデータベース機能を導入できます。ブルー/グリーンデプロイでは、エンジンのメジャーバージョンまたはマイナーバージョンのアップグレードなど、データベース更新のリスクとダウンタイムが軽減されます。

ブルー/グリーンデプロイには次の利点があります。

  • 本稼働環境に対応したステージング環境を簡単に作成できます。

  • データベースの変更を本稼働環境からステージング環境に自動的にレプリケートします。

  • 本稼働環境に影響を与えずに、安全なステージング環境でデータベースの変更をテストします。

  • データベースパッチとシステムアップデートを最新の状態に保ちます。

  • 新しいデータベース機能を実装してテストします。

  • アプリケーションを変更することなく、ステージング環境を新しい本稼働環境に切り替えます。

  • 組み込みの切り替えガードレールを使用して安全に切り替えることができます。

  • 切り替え中のデータ損失をなくします。

  • ワークロードにもよりますが、通常は 1 分以内にすばやく切り替えることができます。

ブルー/グリーンデプロイのワークフロー

Aurora DB クラスターの更新にブルー/グリーンデプロイを使用する場合は、次の主要なステップを実行します。

  1. 更新が必要な本稼働 DB クラスターを特定します。

    次の図は、本稼働 DB クラスターの例を示しています。

    ブルー/グリーンデプロイの本稼働 (ブルー) Aurora DB クラスター

  2. ブルー/グリーンデプロイを作成します。手順については、ブルー/グリーンデプロイの作成 を参照してください。

    以下の図は、ステップ 1 の本稼働環境のブルー/グリーンデプロイの例を示しています。ブルー/グリーンデプロイを作成する際、RDS は Aurora DB クラスターのトポロジと構成全体をコピーしてグリーン環境を作成します。コピーされた DB クラスターと DB インスタンスの名前には -green-random-characters が付加されます。図のステージング環境には DB クラスター (auroradb-green-abc123) が含まれています。また、DB クラスター内の 3 つの DB インスタンス (auroradb-instance1-green-abc123、auroradb-instance2-green-abc123、auroradb-instance3-green-abc123) も含まれています。

    Amazon Aurora のブルー/グリーンデプロイ

    ブルー/グリーンデプロイを作成すると、グリーン環境で DB クラスターにより高い DB エンジンのバージョンと別の DB パラメータグループを指定できます。DB クラスター内の DB インスタンスに別の DB パラメータグループを指定することもできます。

    RDS は、ブルー環境のプライマリ DB インスタンスからグリーン環境のプライマリ DB インスタンスへのレプリケーションも設定します。

    重要

    Aurora MySQL バージョン 3 では、ブルー/グリーンデプロイを作成すると、グリーン環境の DB クラスターはデフォルトで書き込み操作を許可します。read_only パラメータ を 1 に設定し、クラスターを再起動して、DB クラスターを読み取り専用にすることをお勧めします。

  3. ステージング環境に変更を加えます。

    例えば、データベースにスキーマの変更を加えたり、グリーン環境の 1 つ以上の DB インスタンスが使用する DB インスタンスクラスを変更したりすることができます。

    DB クラスターの変更については、「Amazon Aurora DB クラスターの変更」を参照してください。

  4. ステージング環境をテストします。

    テスト中は、グリーン環境のデータベースを読み取り専用に保つことをお勧めします。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作を有効にします。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。Aurora MySQL の書き込み操作を有効にするには、read_only パラメータを 0 に設定し、DB インスタンスを再起動します。Aurora PostgreSQL の場合、セッションレベルで default_transaction_read_only パラメータを off に設定します。

  5. 準備ができたら切り替えて、ステージング環境を昇格させ、新しい本稼働データベース環境にします。手順については、ブルー/グリーンデプロイの切り替え を参照してください。

    切り替えによりダウンタイムが発生します。ダウンタイムは通常 1 分未満ですが、ワークロードによってはさらに長くなることもあります。

    次の図は、切り替え後の DB クラスターを示しています。

    Amazon Aurora ブルー/グリーンデプロイの切り替え後の DB クラスターと DB インスタンス

    切り替え後、グリーン環境の Aurora DB クラスターが新しい実稼働 DB クラスターになります。現在の本稼働環境の名前とエンドポイントは、新しく昇格した本稼働環境に割り当てられるため、アプリケーションを変更する必要はありません。その結果、本稼働トラフィックが新しい本稼働環境に流れるようになります。ブルー環境の DB クラスターと DB インスタンスは、現在の名前に -oldn を付加することで名前が変更されます (n は数字です)。例えば、ブルー環境の DB インスタンスの名前が auroradb-instance-1 であるとします。切り替え後、DB インスタンス名は auroradb-instance-1-old1 になります。

    図の例では、切り替え中に次の変更が行われます。

    • グリーン環境の DB クラスター auroradb-green-abc123 は、auroradb という名前の付いた本稼働用 DB クラスターになります。

    • グリーン環境の auroradb-instance1-green-abc123 という名前の DB インスタンスは、本稼働 DB インスタンス auroradb-instance1 になります。

    • グリーン環境の auroradb-instance2-green-abc123 という名前の DB インスタンスは、本稼働 DB インスタンス auroradb-instance2 になります。

    • グリーン環境の auroradb-instance3-green-abc123 という名前の DB インスタンスは、本稼働 DB インスタンス auroradb-instance3 になります。

    • ブルー環境の auroradb という名前の DB クラスターは auroradb-old1 になります。

    • ブルー環境の auroradb-instance1 という名前の DB インスタンスは auroradb-instance1-old1 になります。

    • ブルー環境の auroradb-instance2 という名前の DB インスタンスは auroradb-instance2-old1 になります。

    • ブルー環境の auroradb-instance3 という名前の DB インスタンスは auroradb-instance3-old1 になります。

  6. 不要になったブルー/グリーンデプロイは削除できます。手順については、ブルー/グリーンデプロイの削除 を参照してください。

    切り替え後も以前の本稼働環境は削除されないため、必要に応じてリグレッションテストに使用できます。

ブルー/グリーンデプロイオペレーションへのアクセスの承認

ブルー/グリーンデプロイに関連する操作を実行するには、ユーザーは必要なアクセス許可があることが求められます。指定されたリソースに対して特定の API 操作を実行するために必要なアクセス許可をユーザーとロールに付与する IAM ポリシーを作成できます。その後、これらのポリシーを、それらのアクセス許可を必要とする IAM アクセス許可セットまたはロールにアタッチできます。詳細については、「Amazon Aurora での Identity and Access Management」を参照してください。

ブルー/グリーンデプロイを作成するユーザーには、次の RDS オペレーションを実行するアクセス許可が必要です。

  • rds:AddTagsToResource

  • rds:CreateDBCluster

  • rds:CreateDBInstance

  • rds:CreateDBClusterEndpoint

ブルー/グリーンデプロイを切り替えるユーザーには、次の RDS オペレーションを実行するアクセス許可が必要です。

  • rds:ModifyDBCluster

  • rds:PromoteReadReplicaDBCluster

ブルー/グリーンデプロイを削除するユーザーには、次の RDS オペレーション (複数可) を実行するアクセス許可が必要です。

  • rds:DeleteDBCluster

  • rds:DeleteDBInstance

  • rds:DeleteDBClusterEndpoint

Aurora は、お客様に代わってステージング環境のリソースをプロビジョニングおよび変更します。これらのリソースには、内部で定義された命名規則を使用する DB インスタンスが含まれます。したがって、アタッチされた IAM ポリシーには、my-db-prefix-* のような部分的なリソース名パターンを含めることはできません。ワイルドカード (*) のみがサポートされています。一般的に、これらのリソースへのアクセスを制御するには、ワイルドカードではなく、リソースタグやその他のサポートされている属性を使用することをおすすめします。詳細については、「Amazon RDS のアクション、リソース、および条件キー」を参照してください。

ブルー/グリーンデプロイの考慮事項

Amazon RDS は、ブルー/グリーンデプロイのリソースを各リソースの DbiResourceIdおよび DbClusterResourceId で追跡します。このリソース ID は、リソースの AWS リージョン 固有のイミュータブルな識別子です。

リソース ID は、DB クラスター ID とは異なります。

ブルー/グリーンデプロイを作成する

ブルー/グリーンデプロイを切り替えると、リソースの名前 (クラスター ID) は変わりますが、各リソースは同じリソース ID を保持します。例えば、DB クラスター識別子がブルー環境で mycluster であったとします。切り替え後、同じ DB クラスターの名前が mycluster-old1 に変更されたとします。ただし、DB クラスターのリソース ID は切り替え中に変更されません。そのため、グリーンリソースを新しい本稼働用リソースに昇格しても、そのリソース ID は以前に本稼働にあったブルーリソース ID と一致しません。

ブルー/グリーンデプロイに切り替えたら、本稼働用リソースで使用していた統合機能やサービスのリソース ID を新たにプロモートされた本稼働用リソースのものに更新することを検討してください。具体的には、次のような更新を検討してください。

  • RDS API とリソース ID を使用してフィルタリングを実行する場合は、切り替え後にフィルタリングに使用されるリソース ID を調整します。

  • CloudTrail をリソースの監査に使用する場合は、切り替え後に新しいリソース ID を追跡するように CloudTrail のコンシューマーを調整します。詳細については、「AWS CloudTrail での Amazon Aurora API コールのモニタリング」を参照してください。

  • ブルー環境のリソースにデータベースアクティビティストリームを使用する場合は、切り替え後に新しいストリームのデータベースイベントをモニタリングするようにアプリケーションを調整します。詳細については、「Aurora でのデータベースアクティビティストリーミング」を参照してください。

  • パフォーマンスインサイト API を使用する場合は、切り替え後に API への呼び出しでリソース ID を調整します。詳細については、「Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング」を参照してください。

    切り替え後に同じ名前のデータベースをモニタリングできますが、切り替え前のデータは含まれていません。

  • IAM ポリシーでリソース ID を使用する場合は、必要に応じて新しく昇格したリソースのリソース ID を追加します。詳細については、「Amazon Aurora での Identity and Access Management」を参照してください。

  • DB クラスターに IAM ロールが関連付けられている場合は、スイッチオーバー後にそれらを再度関連付けます。アタッチされたロールはグリーンの環境に自動的にコピーされません。

  • IAM データベース認証を使用して DB クラスターを認証する場合は、データベースアクセスに使用する IAM ポリシーの Resource 要素の下にブルーとグリーンのデータベースの両方が表示されていることを確認してください。これは、スイッチオーバー後にグリーンのデータベースに接続するために必要です。詳細については、「IAM データベースアクセス用の IAM ポリシーの作成と使用」を参照してください。

  • ブルー/グリーンデプロイに含まれていた DB クラスターの手動 DB クラスタースナップショットを復元する場合は、スナップショットが取られた時間を調べて、正しい DB クラスタースナップショットを復元します。詳細については、「DB クラスターのスナップショットからの復元」を参照してください。

  • Amazon Aurora は、基盤となるブルー環境の Aurora ストレージボリュームをクローニングすることでグリーン環境を作成します。グリーンのクラスターボリュームには、グリーン環境に加えられた増分変更のみが保存されます。ブルー環境の DB クラスターを削除すると、グリーン環境の基盤となる Aurora ストレージボリュームのサイズは、フルサイズまで増大します。詳細については、「Amazon Aurora DB クラスターのボリュームのクローン作成」を参照してください。

  • ブルー/グリーンデプロイのグリーン環境の DB クラスターに DB インスタンスを追加すると、切り替え時にブルー環境の DB インスタンスが新しい DB インスタンスに置き換わることはありません。ただし、新しい DB インスタンスは DB クラスターに残り、新しい本稼働環境の DB インスタンスになります。

  • ブルー/グリーンデプロイのグリーン環境で DB クラスターの DB インスタンスを削除すると、ブルー/グリーンデプロイで代わりになる新しい DB インスタンスを作成することはできません。

    削除した DB インスタンスと同じ名前と ARN で新しい DB インスタンスを作成する場合、DbiResourceId が異なるため、グリーン環境には含まれません。

    グリーン環境で DB クラスター内の DB インスタンスを削除すると、次のような動作になります。

    • ブルー環境に同じ名前の DB インスタンスが存在する場合、グリーン環境の DB インスタンスに切り替わりません。この DB インスタンスの名前は、DB インスタンス名に -oldn を付加することによって変更されません。

    • ブルー環境の DB インスタンスを参照するアプリケーションは、切り替え後も同じ DB インスタンスを引き続き使用します。

ブルー/グリーンデプロイのベストプラクティス

ブルー/グリーンデプロイのベストプラクティスを以下に示します。

一般的なベストプラクティス

  • 切り替える前に、Aurora DB クラスターをグリーン環境で十分にテストしてください。

  • グリーン環境のデータベースは読み取り専用のまま維持してください。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作の有効化には注意することをお勧めします。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。

  • ブルー/グリーンデプロイを使用してスキーマの変更を実装する場合は、レプリケーション互換の変更のみを行ってください。

    例えば、ブルーデプロイからグリーンデプロイへのレプリケーションを中断することなく、テーブルの最後に新しい列を追加する、インデックスを作成する、またはインデックスを削除することができます。ただし、列名の変更やテーブル名の変更などのスキーマの変更は、グリーンデプロイへのレプリケーションを中断させます。

    レプリケーションと互換性のある変更の詳細については、MySQL ドキュメントの「ソースとレプリカのテーブル定義が異なるレプリケーション」と PostgreSQL 論理レプリケーションドキュメントの「制限」を参照してください。

  • 両方の環境のすべての接続に、クラスターエンドポイント、リーダーエンドポイント、またはカスタムエンドポイントを使用します。静的リストまたは除外リストのあるインスタンスエンドポイントやカスタムエンドポイントは使用しないでください。

  • ブルー/グリーンデプロイメントを切り替えるときは、切り替えのベストプラクティスに従ってください。詳細については、「切り替えのベストプラクティス」を参照してください。

Aurora PostgreSQL のベストプラクティス

  • Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュをモニタリングし、必要に応じてキャッシュバッファを調整します。詳細については、「Aurora PostgreSQL 論理レプリケーションライトスルーキャッシュの管理」を参照してください。

  • データベースが に十分な空きメモリがある場合は、ブルー環境の logical_decoding_work_mem DB パラメータの値を増やします。そうすることで、ディスク上でのデコード回数が減り、代わりにメモリを消費します。FreeableMemory CloudWatch メトリクスを使用して空きメモリをモニタリングできます。詳細については、「Amazon Aurora の Amazon CloudWatch メトリクス」を参照してください。

  • ブルー/グリーンデプロイを作成するときには、すべての PostgreSQL 拡張機能を最新バージョンに更新してください。詳細については、「PostgreSQL 拡張機能のアップグレード」を参照してください。

  • aws_s3 拡張機能を使用している場合は、グリーン環境が作成された後に、必ず IAM ロールを通じてグリーン DB クラスターに Amazon S3 へのアクセスを許可してください。これにより、インポートコマンドとエクスポートコマンドは、スイッチオーバー後も機能し続けることができます。手順については、Amazon S3 バケットへのアクセスを設定する を参照してください。

リージョンとバージョンの可用性

機能の可用性とサポートは、各データベースエンジンの特定のバージョン、および AWS リージョン によって異なります。Amazon RDS ブルー/グリーンデプロイに関するバージョンと利用可能なリージョンの詳細については、「ブルー/グリーンデプロイ」を参照してください。

ブルー/グリーンデプロイの制限事項

ブルー/グリーンデプロイには、次の制約事項が適用されます。

ブルー/グリーンデプロイの一般的な制約事項

ブルー/グリーンデプロイには、次の一般的な制約事項が適用されます。

  • Aurora MySQL バージョン 2.08 と 2.09 は、アップグレードのソースバージョンまたはターゲットバージョンとしてはサポートされません。

  • ブルー/グリーンデプロイの一部であるクラスターを停止および開始することはできません。

  • ブルー/グリーンデプロイでは、AWS Secrets Manager を使用したマスターユーザーのパスワード管理はサポートされていません。

  • Aurora MySQL の場合、ソース DB クラスターには tmp という名前のデータベースを含めることはできません。この名前のデータベースはグリーン環境にコピーされません。

  • Aurora PostgreSQL では、ブルー DB クラスターで rds.logically_replicate_unlogged_tables パラメータが 1 に設定されていない限り、ログに記録されていないテーブルはグリーン環境にレプリケートされません。ブルー/グリーンデプロイを作成した後は、ログに記録されていないテーブルで発生する可能性のあるレプリケーションエラーを回避するために、このパラメータ値を変更しないことをお勧めします。

  • Aurora PostgreSQL では、ブルー環境の DB クラスターを自己管理の論理ソース (パブリッシャー) またはレプリカ (サブスクライバー) にすることはできません。Aurora MySQL では、ブルー環境の DB クラスターを外部バイナリログレプリカにすることはできません。

  • 切り替え中、ブルー環境とグリーン環境では Amazon Redshift とのゼロ ETL 統合はできません。最初に統合を削除してから切り替えて、統合を再作成する必要があります。

  • ブルー/グリーンデプロイを作成するときには、グリーン環境でイベントスケジューラー (event_scheduler パラメーター) を無効にする必要があります。これにより、グリーン環境でイベントが生成されて不整合が発生するのを防ぐことができます。

  • ブルーの DB クラスターで定義されている Aurora Auto Scaling ポリシーはグリーンの環境にコピーされません。

  • ブルー/グリーンデプロイは AWS JDBC ドライバー for MySQL をサポートしていません。詳細については、GitHub の「既知の制限事項」を参照してください。

  • ブルー/グリーンデプロイは、以下の機能ではサポートされていません。

    • Amazon RDS Proxy

    • クロスリージョンリードレプリカ

    • Aurora Serverless v1 DB クラスター

    • Aurora Global Database の一部である DB クラスター。

    • Babelfish for Aurora PostgreSQL

    • AWS CloudFormation

ブルー/グリーンデプロイの PostgreSQL 拡張機能の制約事項

以下の制約事項が PostgreSQL 拡張機能に適用されます。

  • ブルー/グリーンデプロイを作成するときには、ブルー環境で pg_partman 拡張機能を無効にする必要があります。この拡張機能は CREATE TABLE などの DDL オペレーションを実行します。これは、ブルー環境からグリーン環境への論理レプリケーションを中断します。

  • ブルー/グリーンデプロイを作成した後は、すべてのグリーンデータベースで pg_cron 拡張機能を無効のままにしておく必要があります。この拡張機能には、スーパーユーザーとして実行されるバックグラウンドワーカーがあり、グリーン環境の読み取り専用設定をバイパスするため、レプリケーションの競合が発生する可能性があります。

  • ブルー環境で同じプランが取り込まれた場合、プライマリキーの競合が発生しないように、apg_plan_mgmt 拡張機能の apg_plan_mgmt.capture_plan_baselines パラメータをすべてのグリーンデータベースで off に設定する必要があります。詳細については、「Aurora PostgreSQL のクエリプラン管理の概要」を参照してください。

    Aurora Replicas で実行プランをキャプチャする場合は、apg_plan_mgmt.create_replica_plan_capture 関数を呼び出すときにブルー DB クラスターエンドポイントを指定する必要があります。これにより、プランのキャプチャはスイッチオーバー後も引き続き機能します。詳細については、「レプリカでの Aurora PostgreSQL 実行プランのキャプチャ」を参照してください。

  • ブルー DB クラスターが外部データラッパー (FDW) 拡張機能の外部サーバーとして設定されている場合は、IP アドレスの代わりにクラスターエンドポイント名を使用する必要があります。これにより、スイッチオーバー後も設定は機能し続けます。

  • ブルー/グリーンデプロイを作成するときには、ブルー環境で pglogical および pg_active 拡張機能を無効にする必要があります。グリーン環境を新しい本番環境に昇格させたら、拡張機能を再度有効にできます。また、ブルーデータベースは外部インスタンスの論理サブスクライバーにはなれません。

  • pgAudit 拡張機能を使用している場合は、ブルー DB インスタンスとグリーン DB インスタンスの両方のカスタム DB パラメータグループの共有ライブラリ (shared_preload_libraries) に残っている必要があります。詳細については、「pgAudit 拡張機能のセットアップ」を参照してください。

ブルー/グリーンデプロイの変更の制約事項

ブルー/グリーンデプロイの変更に関する制約事項を次に示します。

  • 暗号化されていない DB クラスターを暗号化された DB クラスターに変更することはできません。

  • 暗号化された DB クラスターを暗号化されていない DB クラスターに変更することはできません。

  • ブルー環境の DB クラスターを、対応するグリーン環境の DB クラスターよりも上位のエンジンバージョンに変更することはできません。

  • ブルー環境とグリーン環境のリソースは同じ AWS アカウント にある必要があります。

  • ブルー環境に Aurora Auto Scaling ポリシーが含まれている場合、これらのポリシーはグリーンの環境にコピーされません。グリーン環境にはポリシーを手動で再追加する必要があります。

ブルー/グリーンデプロイの PostgreSQL 論理レプリケーションの制約事項

ブルー/グリーンデプロイでは、論理レプリケーションを使用してステージング環境と運用環境の同期を保ちます。PostgreSQL には、論理レプリケーションに関連する特定の制約事項があります。これは、Aurora PostgreSQL DB クラスター のブルー/グリーンデプロイを作成する際の制約となります。

次の表では、Aurora PostgreSQL のブルー/グリーンデプロイメントに適用される論理レプリケーションの制約事項について説明しています。

制限 説明
CREATE TABLE や CREATE SCHEMA などのデータ定義言語 (DDL) ステートメントは、ブルー環境からグリーン環境にはレプリケートされません。

Aurora がブルーの環境で DDL の変更を検出すると、グリーンデータベースはレプリケーションが低下した状態になります。

ブルー環境での DDL の変更を緑の環境にレプリケートできないことを通知するイベントを受け取ります。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。そうしないと、ブルー/グリーンデプロイに切り替えることができません。
シーケンスオブジェクトに対する NEXTVAL オペレーションは、ブルー環境とグリーン環境では同期されません。

スイッチオーバー中、Aurora はグリーン環境のシーケンス値をブルー環境のシーケンス値と一致するようにインクリメントします。シーケンスが数千ある場合、スイッチオーバーが遅れる可能性があります。
ブルー環境での大きなオブジェクトの作成や変更は、グリーン環境にはレプリケートされません。

Aurora が、pg_largeobject システムテーブルに保存されているブルー環境でラージオブジェクトの作成または変更を検出すると、グリーンデータベースはレプリケーションが低下したの状態になります。

Aurora は、ブルー環境での大きなオブジェクトの変化をグリーン環境にレプリケートできないことを通知するイベントを生成します。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。そうしないと、ブルー/グリーンデプロイに切り替えることができません。

マテリアライズドビューはグリーン環境では自動的に更新されません。

ブルー環境でマテリアライズドビューを更新しても、グリーン環境では更新されません。スイッチオーバー後、マテリアライズドビューの更新をスケジュールできます。

UPDATE および DELETE オペレーションは、プライマリキーのないテーブルでは許可されません。

ブルー/グリーンデプロイを作成する前に、DB クラスター のすべてのテーブルにプライマリキーがあることを確認してください。

詳細については、PostgreSQL の論理レプリケーションドキュメントの「制限」を参照してください。