스키마, 데이터, 메타데이터를 소스 데이터베이스에서 대상 데이터베이스로 마이그레이션할 때는 이 모든 정보가 정확하게 마이그레이션되는지 확인해야 합니다. Database Migration Service는 데이터베이스 객체 (스키마, 데이터, 메타데이터 포함)를 한 데이터베이스에서 다른 데이터베이스로 마이그레이션하는 고화질 방법을 제공합니다.
다음 데이터, 스키마, 메타데이터 구성요소가 모두 데이터베이스 마이그레이션의 일부로 마이그레이션됩니다.
연속 마이그레이션 중에 데이터 조작 언어 (DML) 변경사항만 자동으로 업데이트됩니다. 소스 및 대상 데이터베이스가 계속 호환되도록 데이터 정의 언어 (DDL) 변경사항을 관리하는 것은 사용자의 책임이며 다음 두 가지 방법으로 할 수 있습니다.
소스 쓰기를 중지하고 소스 및 대상 모두에서 DDL 명령어를 실행합니다. 대상에서 DDL 명령어를 실행하기 전에 DDL 변경사항을 적용하는 AlloyDB 사용자에게 alloydbexternalsync 역할을 부여합니다. 데이터 쿼리 또는 변경을 사용 설정하려면 관련 AlloyDB 사용자에게 alloydbexternalsync 역할을 부여합니다.
pglogical.replicate_ddl_command를 사용하여 소스 및 대상의 일관된 지점에서 DDL을 실행합니다. 이 명령어를 실행하는 사용자는 소스와 대상 모두에서 동일한 사용자 이름을 사용해야 하며, 마이그레이션되는 아티팩트(예: 테이블, 시퀀스, 뷰 또는 데이터베이스)의 슈퍼사용자 또는 소유자여야 합니다.
다음은 pglogical.replicate_ddl_command 사용의 몇 가지 예입니다.
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default}');
기본 키가 없는 데이터베이스 테이블 이름 변경
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default_insert_only}');
기본 키가 있는 데이터베이스 테이블 만들기
다음 명령어를 실행합니다.
selectpglogical.replicate_ddl_command(command:='CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',replication_sets:=ARRAY['default']);
selectpglogical.replicate_ddl_command(command:='CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',replication_sets:=ARRAY['default_insert_only']);
PostgreSQL의 논리적 디코딩 기능이 대규모 객체의 변경사항 디코딩을 지원하지 않으므로 대규모 객체는 복제할 수 없습니다. 대용량 객체를 참조하는 열 유형 oid가 있는 테이블의 경우 행이 동기화되고 새 행이 복제됩니다.
그러나 대상 데이터베이스의 대용량 객체에 액세스하려고 하면(lo_get를 사용하여 읽거나, lo_export를 사용하여 내보내거나, 지정된 oid의 카탈로그 pg_largeobject를 확인) 대용량 객체가 존재하지 않는다는 메시지와 함께 실패합니다.
기본 키가 없는 테이블의 경우 Database Migration Service는 변경 데이터 캡처 (CDC) 단계 중에 초기 스냅샷과 INSERT 문의 마이그레이션을 지원합니다. UPDATE 및 DELETE 문은 수동으로 마이그레이션해야 합니다.
Database Migration Service는 구체화된 뷰의 데이터가 아닌 뷰 스키마만 마이그레이션합니다. 뷰를 채우려면 REFRESH MATERIALIZED VIEW view_name 명령어를 실행합니다.
새 대상의 SEQUENCE 상태 (예: last_value)는 소스 SEQUENCE 상태와 다를 수 있습니다.
맞춤설정된 테이블스페이스는 대상 Cloud SQL 인스턴스에서 지원되지 않습니다. 맞춤설정된 테이블스페이스 내의 모든 데이터가 Cloud SQL의 기본 pg_default 테이블스페이스로 마이그레이션됩니다.
[[["이해하기 쉬움","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 ensures high-fidelity migration of database objects, including schema, data, and metadata, from one database to another.\u003c/p\u003e\n"],["\u003cp\u003eDuring migration, all tables, naming, primary keys, data types, default values, nullability, auto-increment attributes, secondary indexes, stored procedures, functions, triggers, views, and foreign key constraints are migrated.\u003c/p\u003e\n"],["\u003cp\u003eDuring continuous migrations, only data manipulation language (DML) changes are updated automatically, while data definition language (DDL) changes are managed by the user to maintain source and destination compatibility.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service does not migrate large objects, \u003ccode\u003eUPDATE\u003c/code\u003e and \u003ccode\u003eDELETE\u003c/code\u003e statements for tables without primary keys, data from materialized views, and it migrates customized tablespaces to the default tablespace in the destination.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eSEQUENCE\u003c/code\u003e states on the destination database might differ from those on the source database after the migration.\u003c/p\u003e\n"]]],[],null,["# Migration fidelity\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/migration-fidelity \"View this page for the MySQL version of Database Migration Service.\") \\| [PostgreSQL](/database-migration/docs/postgres/migration-fidelity \"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\nOverview\n--------\n\nWhen you're migrating your schema, data, and metadata from a source database to a\ndestination database, you want to ensure that all of this information is\nmigrated accurately. Database Migration Service provides a high-fidelity way to\nmigrate database objects (including the schema, data, and metadata) from one\ndatabase to another.\n\nAll of the following data, schema, and metadata components are migrated as part\nof the database migration:\n\n### Data\n\n- All tables from all databases and schemas, excluding the following schemas:\n\n - The information schema `information_schema`\n - Any schemas beginning with `pg` (for example, `pg_catalog`)\n\n For more information about these schemas, see [Known limitations](/database-migration/docs/postgresql-to-alloydb/known-limitations).\n\n### Schema\n\n- Naming\n\n- Primary key\n\n- Data type\n\n- Ordinal position\n\n- Default value\n\n- Nullability\n\n- Auto-increment attributes\n\n- Secondary indexes\n\n### Metadata\n\n- Stored procedures\n\n- Functions\n\n- Triggers\n\n- Views\n\n- Foreign key constraints\n\n### Continuous migration\n\nOnly data manipulation language (DML) changes are updated automatically during\ncontinuous migrations. Managing data definition language (DDL) changes so that the source and destination databases remain compatible is the\nresponsibility of the user, and can be achieved in two ways:\n\n1. Stopping writes to the source and running the DDL commands in both source and destination. Before running DDL commands on the destination, grant `alloydbexternalsync` to the AlloyDB user applying the DDL changes. To enable querying or changing the data, grant the `alloydbexternalsync` role to the relevant AlloyDB users.\n2. Using the `pglogical.replicate_ddl_command` to allow DDL to be run on the source and destination at a consistent point. The user running this command must have the same username on both the source and the destination, and should be the superuser or the owner of the artifact being migrated (for example, the table, sequence, view, or database).\n\n Here are a few examples of using the `pglogical.replicate_ddl_command`.\n\n Replace:\n - \u003cvar label=\"schema\" translate=\"no\"\u003e[SCHEMA]\u003c/var\u003e with the name of the table schema you want to use\n - \u003cvar label=\"table\" translate=\"no\"\u003e[TABLE_NAME]\u003c/var\u003e with the table name\n - \u003cvar label=\"new_table_name\" translate=\"no\"\u003e[NEW_NAME_FOR_TABLE]\u003c/var\u003e with the new name for the table when when performing the rename operation\n\n #### Add a column to a database table with a primary key\n\n \u003cbr /\u003e\n\n ```sql\n select pglogical.replicate_ddl_command(\n 'ALTER TABLE \u003cvar label=\"schema\" translate=\"no\"\u003e[SCHEMA]\u003c/var\u003e.\u003cvar label=\"table\" translate=\"no\"\u003e[TABLE_NAME]\u003c/var\u003e add column surname varchar(20)',\n '{default}'\n );\n ```\n\n \u003cbr /\u003e\n\n #### Add a column to a database table without a primary key\n\n \u003cbr /\u003e\n\n ```sql\n select pglogical.replicate_ddl_command(\n 'ALTER TABLE \u003cvar label=\"schema\" translate=\"no\"\u003e[SCHEMA]\u003c/var\u003e.\u003cvar label=\"table\" translate=\"no\"\u003e[TABLE_NAME]\u003c/var\u003e add column surname varchar(20)',\n '{default_insert_only}'\n );\n ```\n\n \u003cbr /\u003e\n\n #### Change the name of a database table with a primary key\n\n \u003cbr /\u003e\n\n ```sql\n select pglogical.replicate_ddl_command(\n 'ALTER TABLE \u003cvar label=\"schema\" translate=\"no\"\u003e[SCHEMA]\u003c/var\u003e.\u003cvar label=\"table\" translate=\"no\"\u003e[TABLE_NAME]\u003c/var\u003e RENAME TO \u003cvar label=\"new_table_name\" translate=\"no\"\u003e[NEW_NAME_FOR_TABLE]\u003c/var\u003e',\n '{default}'\n );\n ```\n\n \u003cbr /\u003e\n\n #### Change the name of a database table without a primary key\n\n \u003cbr /\u003e\n\n ```sql\n select pglogical.replicate_ddl_command(\n 'ALTER TABLE \u003cvar label=\"schema\" translate=\"no\"\u003e[SCHEMA]\u003c/var\u003e.\u003cvar label=\"table\" translate=\"no\"\u003e[TABLE_NAME]\u003c/var\u003e RENAME TO \u003cvar label=\"new_table_name\" translate=\"no\"\u003e[NEW_NAME_FOR_TABLE]\u003c/var\u003e',\n '{default_insert_only}'\n );\n ```\n\n \u003cbr /\u003e\n\n #### Create a database table with a primary key\n\n Run the following commands:\n 1.\n\n ```sql\n select pglogical.replicate_ddl_command(\n command := 'CREATE TABLE \u003cvar label=\"schema\" translate=\"no\"\u003e[SCHEMA]\u003c/var\u003e.\u003cvar label=\"table\" translate=\"no\"\u003e[TABLE_NAME]\u003c/var\u003e\n (id INTEGER PRIMARY KEY, name VARCHAR);',\n replication_sets := ARRAY['default']\n );\n ```\n 2.\n\n ```sql\n select pglogical.replication_set_add_table('default', '\u003cvar label=\"schema\" translate=\"no\"\u003e[SCHEMA]\u003c/var\u003e.\u003cvar label=\"table\" translate=\"no\"\u003e[TABLE_NAME]\u003c/var\u003e');\n ```\n\n \u003cbr /\u003e\n\n #### Create a database table without a primary key\n\n Run the following commands:\n 1.\n\n ```sql\n select pglogical.replicate_ddl_command(\n command := 'CREATE TABLE \u003cvar label=\"schema\" translate=\"no\"\u003e[SCHEMA]\u003c/var\u003e.\u003cvar label=\"table\" translate=\"no\"\u003e[TABLE_NAME]\u003c/var\u003e\n (id INTEGER PRIMARY KEY, name VARCHAR);',\n replication_sets := ARRAY['default_insert_only']\n );\n ```\n 2.\n\n ```sql\n select pglogical.replication_set_add_table(\n 'default_insert_only', '\u003cvar label=\"schema\" translate=\"no\"\u003e[SCHEMA]\u003c/var\u003e.\u003cvar label=\"table\" translate=\"no\"\u003e[TABLE_NAME]\u003c/var\u003e'\n );\n ```\n\n \u003cbr /\u003e\n\n### What isn't migrated\n\n- [Large objects](https://www.postgresql.org/docs/current/largeobjects.html)\n can't be replicated, as PostgreSQL's logical decoding facility does not support\n decoding changes to large objects. For tables that have column type\n [`oid`](https://www.postgresql.org/docs/current/datatype-oid.html)\n referencing large objects, the rows are synced, and new rows are replicated.\n However, trying to access the large object on the destination database\n (read using [`lo_get`](https://www.postgresql.org/docs/current/lo-funcs.html),\n export using [`lo_export`](https://www.postgresql.org/docs/current/lo-funcs.html),\n or check the catalog `pg_largeobject` for the given\n `oid`), fails with a message saying that the large object does\n not exist.\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 destination might vary from the source `SEQUENCE` states.\n\n- Customized tablespaces aren't supported in the destination Cloud SQL instance. All the data inside customized tablespaces is migrated to the default `pg_default` tablespace in Cloud SQL."]]