PostgreSQL データベースを移行元として使用する場合の既知の制限事項は次のとおりです。
pglogical拡張機能は、PostgreSQL 12 以降の生成列のレプリケーションをサポートしていません。テーブル構造（DDL）の変更は、標準の DDL コマンドでは複製されません。レプリケーションに使用される
pglogical拡張機能を使用して実行されたコマンドによってのみ複製されます。たとえば、
pglogicalには、ソース データベースとレプリカの両方で一貫したポイントで DDL を実行できる関数pglogical.replicate_ddl_commandがあります。ソースでこのコマンドを実行するユーザーは、レプリカにすでに存在している必要があります。新しいテーブルのデータを複製するには、
pglogical.replication_set_add_tableコマンドを使用して、新しいテーブルを既存のレプリケーション セットに追加する必要があります。移行中の DDL レプリケーションの詳細については、移行の忠実度のセクションをご覧ください。
主キーのないテーブルの場合、Database Migration Service は、変更データ キャプチャ（CDC）フェーズでの初期スナップショットと
INSERTステートメントの移行をサポートします。UPDATEステートメントとDELETEステートメントは手動で移行する必要があります。Database Migration Service は、マテリアライズド ビューからデータを移行しません。移行するのはビュー スキーマのみです。ビューにデータを入力するには、
REFRESH MATERIALIZED VIEW view_nameコマンドを実行します。新しい AlloyDB の宛先の
SEQUENCE状態（last_valueなど）は、ソースのSEQUENCE状態と異なる場合があります。UNLOGGEDテーブルとTEMPORARYテーブルは複製されず、複製できません。ラージ オブジェクト データ型はサポートされていません。詳しくは、移行の忠実性のセクションをご覧ください。
- 移行できるのは、AlloyDB for PostgreSQL でサポートされている拡張機能とプロシージャル言語のみです。
Database Migration Service は、復元モードのリードレプリカからの移行をサポートしていません。
Database Migration Service は、AWS SCT 拡張機能パックが適用されている Amazon RDS ソースをサポートしていません。
- C で記述されたユーザー定義関数は移行できません。ただし、AlloyDB でサポートされている拡張機能をインストールするときに PostgreSQL データベースにインストールされる関数は移行できます。
ソース データベースに他の拡張機能や手続き型言語が存在する場合、またはそのバージョンがサポートされていない場合、移行ジョブをテストまたは開始すると、ジョブは失敗します。
移行ジョブの開始後に追加されたデータベースは移行されません。
Database Migration Service を使用して移行する場合、特定のデータベース オブジェクト（データベース、テーブル、スキーマなど）を選択することはできません。データベース移行の一環として、すべてのデータベースとスキーマのすべてのテーブルが移行されます。ただし、次のスキーマは除きます。
- 情報スキーマ（
information_schema） pgで始まるスキーマ（pg_catalogなど。システム テーブルとすべての組み込みデータ型、関数、演算子を含むスキーマで、すべてのデータベースに自動的に存在します）。その結果、ユーザーとユーザーロールに関する情報は移行されません。pgで始まるスキーマの一覧をご覧ください。
- 情報スキーマ（
暗号化されたデータベースの復号に顧客管理の暗号鍵が必要な場合、Database Migration Service がその鍵にアクセスできない場合、データベースを移行できません。
ただし、顧客データが
pgcrypto拡張機能で暗号化されている場合は、Database Migration Service を使用してデータを移行できます（AlloyDB が拡張機能をサポートしているため）。Database Migration Service は、暗号化された Amazon Aurora または Amazon RDS データベースからのデータの移行もサポートしています。これらのデータベースは、サービス内で暗号化を透過的に処理します。詳細については、Amazon Aurora リソースの暗号化とAmazon RDS リソースの暗号化をご覧ください。
移行中は宛先の AlloyDB データベースに書き込みが可能であるため、必要に応じて DDL の変更を適用できます。移行プロセスを中断したり、データの整合性に影響を与えたりする可能性があるデータベース構成やテーブル構造を変更しないように注意してください。
トリガーの動作は、トリガーの構成方法によって異なります。デフォルトの動作ではトリガーされませんが、
ALTER EVENT TRIGGERステートメントまたはALTER TABLEステートメントを使用して構成され、トリガー状態が replica または always に設定されている場合、レプリケーション中にレプリカでトリガーされます。セキュリティ定義子を持つ関数は、AlloyDB プライマリで
alloydbexternalsyncによって作成されます。ユーザーによって実行されると、alloydbsuperuserロールとalloydbreplicaロールを持つalloydbexternalsyncの権限で実行されます。セキュリティ定義関数の使用を一部のユーザーに限定することをおすすめします。これを行うには、デフォルトの PUBLIC 権限を取り消してから、実行権限を選択的に付与する必要があります。
既存の宛先クラスタへの移行の制限事項
- 既存の移行先クラスタは空であるか、システム構成データのみを含む必要があります。ユーザーデータ（テーブルなど）を含む既存の宛先クラスタへの移行はサポートされていません。
- 移行ジョブは、宛先クラスタごとに 1 つだけ構成できます。
- セカンダリ クラスタを含むクラスタへの移行はサポートされていません。
- 読み取りプール インスタンスを使用するクラスタへの移行はサポートされています。
AlloyDB for PostgreSQL のクラスタとインスタンスの詳細については、AlloyDB for PostgreSQL の概要をご覧ください。
割り当て
- 同時に最大 2,000 個の接続プロファイルと 1,000 個の移行ジョブを維持できます。この上限に達した後で他の作業を行うには、移行ジョブ（完了したジョブを含む）または接続プロファイルを削除できます。