Saat memigrasikan skema, data, dan metadata dari database sumber ke database tujuan, Anda ingin memastikan bahwa semua informasi ini dimigrasikan secara akurat. Database Migration Service menyediakan cara dengan fidelitas tinggi untuk
memigrasikan objek database (termasuk skema, data, dan metadata) dari satu
database ke database lainnya.
Semua komponen data, skema, dan metadata berikut dimigrasikan sebagai bagian
dari migrasi database:
Data
Semua tabel dari semua database dan skema, kecuali skema berikut:
Skema informasi information_schema
Semua skema yang diawali dengan pg (misalnya, pg_catalog)
Hanya perubahan bahasa pengolahan data (DML) yang diperbarui secara otomatis selama
migrasi berkelanjutan. Mengelola perubahan bahasa definisi data (DDL) agar database sumber dan tujuan tetap kompatibel adalah
tanggung jawab pengguna, dan dapat dilakukan dengan dua cara:
Menghentikan penulisan ke sumber dan menjalankan perintah DDL di sumber dan
tujuan. Sebelum menjalankan perintah DDL di tujuan, berikan
alloydbexternalsync kepada pengguna AlloyDB yang menerapkan perubahan
DDL. Untuk mengaktifkan kueri atau mengubah data, berikan peran alloydbexternalsync kepada pengguna AlloyDB yang relevan.
Menggunakan pglogical.replicate_ddl_command untuk memungkinkan DDL dijalankan
di sumber dan tujuan pada titik yang konsisten. Pengguna yang menjalankan perintah ini harus memiliki nama pengguna yang sama di sumber dan tujuan, dan harus merupakan superuser atau pemilik artefak yang dimigrasikan (misalnya, tabel, urutan, tampilan, atau database).
Berikut beberapa contoh penggunaan pglogical.replicate_ddl_command.
Ganti:
[SCHEMA] dengan nama skema tabel yang ingin Anda gunakan
[TABLE_NAME] dengan nama tabel
[NEW_NAME_FOR_TABLE] dengan nama baru untuk tabel saat melakukan operasi penggantian nama
Menambahkan kolom ke tabel database dengan kunci utama
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default}');
Mengubah nama tabel database tanpa kunci utama
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default_insert_only}');
Membuat tabel database dengan kunci utama
Jalankan perintah berikut:
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']);
Objek besar
tidak dapat direplikasi, karena fasilitas decoding logis PostgreSQL tidak mendukung
perubahan decoding pada objek besar. Untuk tabel yang memiliki jenis kolom
oid
yang mereferensikan objek besar, baris akan disinkronkan, dan baris baru akan direplikasi.
Namun, mencoba mengakses objek besar di database tujuan
(baca menggunakan lo_get,
ekspor menggunakan lo_export,
atau periksa pg_largeobject katalog untuk oid
yang diberikan), gagal dengan pesan yang menyatakan bahwa objek besar tidak
ada.
Untuk tabel yang tidak memiliki kunci utama, Database Migration Service mendukung migrasi snapshot awal dan pernyataan INSERT selama fase pengambilan data perubahan (CDC). Anda harus memigrasikan pernyataan UPDATE dan DELETE secara manual.
Database Migration Service tidak memigrasikan data dari tampilan yang diwujudkan, hanya skema tampilan. Untuk mengisi tampilan, jalankan perintah berikut: REFRESH MATERIALIZED VIEW view_name.
Status SEQUENCE (misalnya, last_value) di tujuan baru mungkin berbeda dari status SEQUENCE sumber.
Tablespace yang disesuaikan tidak didukung di instance Cloud SQL tujuan. Semua data di dalam tablespace yang disesuaikan dimigrasikan ke tablespace pg_default default di Cloud SQL.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]