Database Migration Service는 복구 모드에 있는 읽기 복제본에서 마이그레이션하는 것을 지원하지 않습니다.
Database Migration Service는 AWS SCT 확장 프로그램 팩이 적용된 Amazon RDS 소스를 지원하지 않습니다.
C로 작성된 사용자 정의 함수는 AlloyDB에서 지원하는 확장 프로그램을 설치할 때 PostgreSQL 데이터베이스에 설치되는 함수를 제외하고 이전할 수 없습니다.
소스 데이터베이스에 다른 확장 프로그램과 절차형 언어가 있거나 해당 버전이 지원되지 않는 경우 테스트하거나 마이그레이션 작업을 시작하면 실패합니다.
마이그레이션 작업이 시작된 후에 추가된 데이터베이스는 마이그레이션되지 않습니다.
Database Migration Service를 사용하여 이전할 때는 특정 테이블이나 스키마를 선택할 수 없습니다.
Database Migration Service는 다음을 제외한 모든 테이블과 스키마를 마이그레이션합니다.
정보 스키마 (information_schema)
pg로 시작하는 테이블(예: pg_catalog) pg로 시작하는 PostgreSQL 카탈로그의 전체 목록은 PostgreSQL 문서의 PostgreSQL 시스템 카탈로그를 참고하세요.
사용자 및 사용자 역할에 관한 정보는 이전되지 않습니다.
암호화된 데이터베이스에서 데이터베이스를 복호화하기 위해 고객 관리 암호화 키가 필요하고 Database Migration Service가 키에 액세스할 수 없는 경우 데이터베이스를 마이그레이션할 수 없습니다.
하지만 고객 데이터가 pgcrypto 확장 프로그램으로 암호화된 경우 AlloyDB에서 확장 프로그램을 지원하므로 Database Migration Service를 사용하여 데이터를 마이그레이션할 수 있습니다.
Database Migration Service는 암호화된 Amazon Aurora 또는 Amazon RDS 데이터베이스의 데이터 마이그레이션도 지원합니다. 이러한 데이터베이스는 서비스에서 투명하게 복호화를 처리하기 때문입니다. 자세한 내용은 Amazon Aurora 리소스 암호화 및 Amazon RDS 리소스 암호화를 참고하세요.
필요한 경우 DDL 변경사항을 적용할 수 있도록 마이그레이션 중에 대상 AlloyDB 데이터베이스를 쓸 수 있습니다. 마이그레이션 프로세스를 중단하거나 데이터 무결성에 영향을 미칠 수 있는 데이터베이스 구성 또는 테이블 구조를 변경하지 않도록 주의하세요.
트리거 동작은 구성 방식에 따라 다릅니다. 기본 동작은 트리거되지 않는 것이지만 ALTER EVENT TRIGGER 또는 ALTER TABLE 문을 사용하여 구성되고 트리거 상태가 복제본 또는 항상으로 설정된 경우 복제 중에 복제본에서 트리거됩니다.
보안 정의자가 있는 함수는 AlloyDB 기본에서 alloydbexternalsync에 의해 생성됩니다. 이 스크립트가 사용자에 의해 실행되면 alloydbsuperuser 및 alloydbreplica 역할이 있는 alloydbexternalsync의 권한으로 실행됩니다. 보안 정의자 함수의 사용을 일부 사용자에게만 제한하는 것이 좋습니다. 이렇게 하려면 사용자가 기본 공개 권한을 취소한 다음 실행 권한을 선택적으로 부여해야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[[["\u003cp\u003eDatabase Migration Service supports the migration of initial snapshots and \u003ccode\u003eINSERT\u003c/code\u003e statements for tables without primary keys, but \u003ccode\u003eUPDATE\u003c/code\u003e and \u003ccode\u003eDELETE\u003c/code\u003e statements must be manually migrated.\u003c/p\u003e\n"],["\u003cp\u003eCertain PostgreSQL features are not supported during migration, including \u003ccode\u003eUNLOGGED\u003c/code\u003e and \u003ccode\u003eTEMPORARY\u003c/code\u003e tables, Large Object data types, and read replicas in recovery mode.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service migrates all tables and schemas except for \u003ccode\u003einformation_schema\u003c/code\u003e and tables beginning with \u003ccode\u003epg\u003c/code\u003e, and does not migrate information about users and user roles.\u003c/p\u003e\n"],["\u003cp\u003eWhile the destination AlloyDB database remains writable during migration, modifications to the database configuration or table structures should be avoided to prevent issues.\u003c/p\u003e\n"],["\u003cp\u003eThere are quotas for the amount of migration jobs and connection profiles that can exist at any given time, set to 1,000 and 2,000 respectively, requiring deletion to create space for more.\u003c/p\u003e\n"]]],[],null,["# Known limitations\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/known-limitations \"View this page for the MySQL version of Database Migration Service.\") \\| [PostgreSQL](/database-migration/docs/postgres/known-limitations \"View this page for the PostgreSQL version of Database Migration Service.\") \\| PostgreSQL to AlloyDB\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nKnown limitations for using a PostgreSQL database as a source include:\n\n- The `pglogical` extension doesn't support the replication of [generated columns](https://www.postgresql.org/docs/current/ddl-generated-columns.html) for PostgreSQL 12+.\n\n- Changes to table structures (DDL) aren't replicated through standard DDL\n commands, but only with commands executed using the `pglogical`\n extension used for replication. This includes\n [changes to\n `enum` types](https://www.postgresql.org/docs/current/sql-altertype.html).\n\n - For example, `pglogical` provides a function\n `pglogical.replicate_ddl_command` that allows DDL to be run on\n both the source database and replica at a consistent point. The user\n running this command on the source must already exist on the replica.\n\n - In order to replicate data for new tables, you must use the\n `pglogical.replication_set_add_table` command to add\n the new tables to existing replication sets.\n\n - To learn more about DDL replication while the migration is in\n progress, see the section on\n [migration fidelity](/database-migration/docs/postgresql-to-alloydb/migration-fidelity).\n\n- For tables that don't have primary keys, Database Migration Service supports migration of the **initial snapshot and `INSERT` statements during the change data capture (CDC) phase** . You should migrate `UPDATE` and `DELETE` statements manually.\n\n- Database Migration Service doesn't migrate data from materialized views, just the view schema. To populate the views, run the following command: `REFRESH MATERIALIZED VIEW `\u003cvar translate=\"no\"\u003eview_name\u003c/var\u003e.\n\n- The `SEQUENCE` states (for example, `last_value`) on the new AlloyDB destination might vary from the source `SEQUENCE` states.\n\n- `UNLOGGED` and `TEMPORARY` tables aren't and can't be\n replicated.\n\n- Large Object data type isn't supported. More details in the section on\n [migration fidelity](/database-migration/docs/postgresql-to-alloydb/migration-fidelity).\n\n\u003c!-- --\u003e\n\n- Only [extensions and procedural languages](/alloydb/docs/reference/extensions) that AlloyDB supports for PostgreSQL can be migrated.\n\n\u003c!-- --\u003e\n\n- Database Migration Service doesn't support migrating from read replicas that are in recovery mode.\n\n- Database Migration Service doesn't support Amazon RDS sources where the AWS SCT extension pack is applied.\n\n\u003c!-- --\u003e\n\n- User-defined functions written in C can't be migrated, except for functions that are installed in the PostgreSQL database when you're installing [extensions](/alloydb/docs/reference/extensions) that are supported by AlloyDB.\n\n\u003c!-- --\u003e\n\n- If other extensions and procedural languages exist in the source database, or if their versions aren't supported, then when you test or start the migration job, it will fail.\n\n- Databases that are added after the migration job has started aren't migrated.\n\n\u003c!-- --\u003e\n\n- You can't select specific tables or schemas when you migrate by using Database Migration Service. Database Migration Service migrates all tables and schemas, except for the following:\n - The information schema (`information_schema`).\n - Any tables that begin with `pg`, for example, `pg_catalog`. For the full list of PostgreSQL catalogs that begin with `pg`, see [PostgreSQL system catalogs](https://www.postgresql.org/docs/current/catalogs.html) in the PostgreSQL documentation.\n - Information about users and user roles isn't migrated.\n\n\u003c!-- --\u003e\n\n- If encrypted databases require customer-managed encryption keys to decrypt the databases, and if Database Migration Service doesn't have access to the keys, then the databases can't be migrated.\n\n However, if customer data is encrypted by the [`pgcrypto` extension](/sql/docs/postgres/extensions#miscellaneous-extensions), then the data can be migrated with Database Migration Service (because AlloyDB supports the extension).\n\n Database Migration Service also supports migrating data from encrypted Amazon Aurora or Amazon RDS databases because these databases handle decryption transparently in their services. For more information, see [Encrypting Amazon Aurora resources](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html) and [Encrypting Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html).\n- The destination AlloyDB database is\n writable during the migration\n to allow DDL changes to be applied if needed. Take care not to make any\n changes to the database configuration or table structures which might break\n the migration process or impact data integrity.\n\n- Trigger behavior depends on how they were configured. The default behavior is they\n won't trigger, but if they were configured using the\n `ALTER EVENT TRIGGER` or `ALTER TABLE` statement and the trigger state is set to either replica or always, then they will trigger\n on the replica during replication.\n\n- Functions with security definer will be created by\n `alloydbexternalsync` in AlloyDB primary. When it's\n executed by any users, it will be executed with the privileges of\n `alloydbexternalsync` which has `alloydbsuperuser` and\n `alloydbreplica` roles. It's better to restrict use of a security\n definer function to only some users. To do that, the user should revoke the\n default PUBLIC privileges and then grant execute privilege selectively.\n\n- [Private Service Connect interfaces connectivity method](/database-migration/docs/postgresql-to-alloydb/networking-methods#psc-interfaces)\n is only supported for migrating to existing destination instances.\n If you want to use private IP connectivity and migrate to a new destination\n instance, use VPC peering.\n\n### Limitations for migrations to existing destination clusters\n\n- Your existing destination cluster must be empty or contain only system configuration data. Migrating to existing destination cluster that contain user data (such as tables) isn't supported.\n- You can configure only one migration job per destination cluster.\n- Migrating to clusters with secondary clusters isn't supported.\n- Migrating to clusters with read pool instances **is supported** .\n\n For more information on AlloyDB for PostgreSQL clusters and instances, see\n [AlloyDB for PostgreSQL overview](/alloydb/docs/overview).\n\n### Quotas\n\n- Up to 2,000 connection profiles and 1,000 migration jobs can exist at any given time. To create space for more, migration jobs (including completed ones) and connection profiles can be deleted."]]
