데이터베이스를 Cloud SQL로 마이그레이션하기 전에 이 마이그레이션 시나리오의 알려진 제한사항을 고려해야 합니다.
PostgreSQL 데이터베이스를 소스로 사용할 경우의 알려진 제한사항은 다음과 같습니다.
pglogical 확장 프로그램은 PostgreSQL 12 이상의 생성된 열 복제를 지원하지 않습니다.
표 구조 (DDL)의 변경사항은 표준 DDL 명령어를 통해 복제되지 않고 복제에 사용되는 pglogical 확장 프로그램을 사용하여 실행된 명령어만 복제됩니다. 여기에는 enum 유형 변경이 포함됩니다.
예를 들어 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 명령어를 실행합니다.
새 Cloud SQL 대상의 SEQUENCE 상태 (예: last_value)는 소스 SEQUENCE 상태와 다를 수 있습니다.
UNLOGGED 및 TEMPORARY 테이블은 복제되지 않으며 복제할 수 없습니다.
Large Object 데이터 유형은 지원되지 않습니다. 자세한 내용은 마이그레이션 충실도 섹션을 참고하세요.
PostgreSQL용 Cloud SQL에서 지원하는 확장 프로그램 및 절차적 언어만 이전할 수 있습니다.
Database Migration Service는 Cloud SQL에서 지원하지 않는 확장 프로그램을 마이그레이션하지 않습니다. 이러한 확장 프로그램이 있어도 마이그레이션이 차단되지는 않지만 원활한 마이그레이션 프로세스를 위해 객체나 애플리케이션이 지원되지 않는 확장 프로그램을 참조하지 않는지 확인하세요. 진행하기 전에 소스 데이터베이스에서 이러한 확장 프로그램과 참조를 삭제하는 것이 좋습니다.
pg_cron 확장 프로그램 (또는 확장 프로그램과 연결된 cron 설정)은 Database Migration Service에서 마이그레이션되지 않지만 PostgreSQL용 Cloud SQL 대상에서 지원됩니다. 소스 데이터베이스에서 pg_cron 확장 프로그램을 사용하는 경우 마이그레이션이 완료된 후 대상 인스턴스에 다시 설치할 수 있습니다.
Database Migration Service는 복구 모드에 있는 읽기 복제본에서 마이그레이션하는 것을 지원하지 않습니다.
Database Migration Service는 AWS SCT 확장 프로그램 팩이 적용된 Amazon RDS 소스를 지원하지 않습니다.
C로 작성된 사용자 정의 함수는 Cloud SQL에서 지원하는 확장 프로그램을 설치할 때 PostgreSQL 데이터베이스에 설치되는 함수를 제외하고 마이그레이션할 수 없습니다.
소스 데이터베이스에 다른 확장 프로그램과 절차형 언어가 있거나 해당 버전이 지원되지 않는 경우 테스트하거나 마이그레이션 작업을 시작하면 실패합니다.
마이그레이션 작업이 시작된 후에 추가된 데이터베이스는 마이그레이션되지 않습니다.
Database Migration Service를 사용하여 이전할 때는 특정 테이블이나 스키마를 선택할 수 없습니다.
Database Migration Service는 다음을 제외한 모든 테이블과 스키마를 마이그레이션합니다.
정보 스키마 (information_schema)
pg로 시작하는 테이블(예: pg_catalog) pg로 시작하는 PostgreSQL 카탈로그의 전체 목록은 PostgreSQL 문서의 PostgreSQL 시스템 카탈로그를 참고하세요.
사용자 및 사용자 역할에 관한 정보는 이전되지 않습니다.
암호화된 데이터베이스에서 데이터베이스를 복호화하기 위해 고객 관리 암호화 키가 필요하고 Database Migration Service가 키에 액세스할 수 없는 경우 데이터베이스를 마이그레이션할 수 없습니다.
하지만 고객 데이터가 pgcrypto 확장 프로그램으로 암호화된 경우 데이터는 Database Migration Service를 사용하여 마이그레이션할 수 있습니다 (Cloud SQL에서 확장 프로그램을 지원하므로).
Database Migration Service는 암호화된 Amazon Aurora 또는 Amazon RDS 데이터베이스의 데이터 마이그레이션도 지원합니다. 이러한 데이터베이스는 서비스에서 투명하게 복호화를 처리하기 때문입니다. 자세한 내용은 Amazon Aurora 리소스 암호화 및 Amazon RDS 리소스 암호화를 참고하세요.
필요한 경우 DDL 변경사항을 적용할 수 있도록 마이그레이션 중에 대상 Cloud SQL 데이터베이스를 쓸 수 있습니다. 마이그레이션 프로세스를 중단하거나 데이터 무결성에 영향을 미칠 수 있는 데이터베이스 구성 또는 테이블 구조를 변경하지 않도록 주의하세요.
트리거 동작은 구성 방식에 따라 다릅니다. 기본 동작은 트리거되지 않는 것이지만 ALTER EVENT TRIGGER 또는 ALTER TABLE 문을 사용하여 구성되고 트리거 상태가 복제본 또는 항상으로 설정된 경우 복제 중에 복제본에서 트리거됩니다.
보안 정의자가 있는 함수는 Cloud SQL 복제본에서 cloudsqlexternalsync에 의해 생성됩니다. 사용자가 실행하면 cloudsqlsuperuser 및 cloudsqlreplica 역할이 있는 cloudsqlexternalsync의 권한으로 실행됩니다. 보안 정의자 함수의 사용을 일부 사용자에게만 제한하는 것이 좋습니다. 이렇게 하려면 사용자가 기본 공개 권한을 취소한 다음 실행 권한을 선택적으로 부여해야 합니다.
Cloud SQL은 맞춤설정된 테이블스페이스를 지원하지 않습니다. 맞춤설정된 테이블스페이스 내의 모든 데이터가 Cloud SQL 대상 인스턴스의 pg_default 테이블스페이스로 마이그레이션됩니다.
인스턴스에 맞춤설정된 백업 설정 (예: 커스텀 백업 위치)이 있으면 인스턴스를 승격한 후 백업 설정을 다시 맞춤설정해야 합니다. 승격 프로세스가 진행되는 동안 Cloud SQL에서 백업 설정을 기본값으로 재설정합니다.
Terraform 사용자: Database Migration Service는 대상 인스턴스의 백업 및 복구 설정을 수정합니다. 이로 인해 대상 인스턴스 설정이 프로비저닝에 사용한 Terraform 구성과 다를 수 있습니다. 이 문제가 발생하면 문제 진단의 안내를 따르세요.
할당량
어느 시점에든지 최대 2,000개의 연결 프로필과 1,000개의 마이그레이션 작업이 존재할 수 있습니다. 더 많은 항목을 위한 여유 공간을 확보하려면 마이그레이션 작업 (완료된 작업 포함) 및 연결 프로필을 삭제하면 됩니다.
[[["이해하기 쉬움","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 for PostgreSQL has limitations regarding the replication of generated columns, DDL commands, and \u003ccode\u003eUPDATE\u003c/code\u003e and \u003ccode\u003eDELETE\u003c/code\u003e statements for tables without primary keys.\u003c/p\u003e\n"],["\u003cp\u003eCertain PostgreSQL features, such as \u003ccode\u003eUNLOGGED\u003c/code\u003e and \u003ccode\u003eTEMPORARY\u003c/code\u003e tables, large object data types, and unsupported extensions, are not supported by the Database Migration Service and cannot be migrated.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service only migrates all tables and schemas in a database, and it does not migrate specific system schemas such as \u003ccode\u003einformation_schema\u003c/code\u003e and tables beginning with \u003ccode\u003epg\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eMigration to existing Cloud SQL instances is limited to instances that are empty or contain only system configuration data, and only one migration job is allowed per destination instance.\u003c/p\u003e\n"],["\u003cp\u003eThe destination Cloud SQL database is writable during the migration process, but users should avoid making changes to the database configuration or table structures that might affect data integrity.\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 \\| [PostgreSQL to AlloyDB](/database-migration/docs/postgresql-to-alloydb/known-limitations \"View this page for the PostgreSQL to AlloyDB version of Database Migration Service.\")\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nBefore you choose to migrate your databases to\nCloud SQL, make sure you consider known limitations for this migration\nscenario.\n| **Note:** You can also use Google Cloud Migration Center to discover possible limitations or gaps in feature support for your specific scenario. See [Discover and import databases](/migration-center/docs/discover-and-import-databases) in the Migration Center documentation.\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/postgres/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 Cloud SQL 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/postgres/migration-fidelity).\n\n\u003c!-- --\u003e\n\n- Only [extensions and procedural languages](/sql/docs/postgres/extensions)\n that Cloud SQL supports for PostgreSQL can be migrated.\n Database Migration Service doesn't migrate extensions that are unsupported by\n Cloud SQL. The presence of these extensions doesn't block the migration,\n but to ensure a smooth migration process verify that your objects or\n applications don't reference any unsupported extensions. We recommend removing\n these extensions and references from your source database before you\n proceed.\n\n- The [`pg_cron`](/sql/docs/postgres/extensions#pg_cron)\n extension (or any `cron` settings associated with the extension)\n isn't migrated by Database Migration Service, but it is supported in\n Cloud SQL for PostgreSQL destinations. If you use the `pg_cron`\n extension in your source databases, you can re-install it on your destination\n instance after the migration is complete.\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](/sql/docs/postgres/extensions) that are supported by Cloud SQL.\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 Cloud SQL 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 Cloud SQL 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 `cloudsqlexternalsync` in Cloud SQL replica. When it's\n executed by any users, it will be executed with the privileges of\n `cloudsqlexternalsync` which has `cloudsqlsuperuser` and\n `cloudsqlreplica` 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- Cloud SQL does not support customized tablespaces. All the data inside customized\n tablespaces is migrated to the `pg_default` tablespace in the\n Cloud SQL destination instance.\n\n- [Private Service Connect interfaces connectivity method](/database-migration/docs/postgres/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\n ### Limitations for migrations to existing destination instances\n\n - Your existing destination instance must be empty or contain only system configuration data. Migrating to existing destination instances that contain user data (such as tables) isn't supported. If you encounter issues due to extra data in your existing destination\n instance, clear the databases in your destination instance and re-try the migration job.\n See [Clear extra\n data from your existing destination instance](/database-migration/docs/postgres/diagnose-issues#clear-ext-instance-data-steps).\n\n - You can configure only one migration job per destination instance.\n - You can only migrate to standalone Cloud SQL instances. Migrating to [external server replicas](/sql/docs/postgres/replication/configure-external-replica) isn't supported.\n - Migrating data to a Cloud SQL instance that has [Private Service Connect](/sql/docs/postgres/about-private-service-connect) enabled isn't supported.\n - After you promote an instance, you must turn on [point-in-time recovery](/sql/docs/postgres/backup-recovery/restore#tips-pitr).\n - If your instance has customized backup settings (for example, a [custom backup location](/sql/docs/postgres/backup-recovery/backing-up#locationbackups)), then after you promote the instance, you must customize your backup settings again. During the promotion process, Cloud SQL resets your backup settings to their default values.\n - **For Terraform users** : Database Migration Service modifies the backup and recovery settings of your destination instance. This might cause the destination instance settings to be different from the Terraform configuration you used for provisioning. If you experience this issue, follow the guidance in [Diagnose issues](/database-migration/docs/postgres/diagnose-issues#existing-instance-terraform-config-drift).\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."]]
