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.
Selama proses migrasi, data dan batasan dimigrasikan secara terpisah.
Data dimigrasikan terlebih dahulu, dan batasan seperti kunci utama, kunci asing,
dan indeks dibuat ulang di instance setelah dump dan pemuatan penuh awal.
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
cloudsqlexternalsync kepada pengguna Cloud SQL yang menerapkan perubahan
DDL. Untuk mengaktifkan kueri atau mengubah data, berikan peran
cloudsqlexternalsync kepada pengguna Cloud SQL 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']);
Untuk menambahkan pengguna ke instance tujuan Cloud SQL, buka instance dan tambahkan pengguna
dari tab Pengguna, atau tambahkan dari klien PostgreSQL. Pelajari lebih lanjut cara membuat
dan mengelola pengguna PostgreSQL.
Database Migration Service tidak memigrasikan ekstensi yang tidak didukung oleh
Cloud SQL. Kehadiran ekstensi ini
tidak memblokir migrasi, tetapi untuk memastikan proses migrasi berjalan lancar,
pastikan objek atau aplikasi Anda tidak mereferensikan ekstensi yang tidak didukung. Sebaiknya hapus ekstensi dan referensi ini dari database sumber sebelum melanjutkan.
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 source to destination databases.\u003c/p\u003e\n"],["\u003cp\u003eDuring migration, data is migrated first, followed by the recreation of constraints such as primary keys, foreign keys, and indexes on the destination instance.\u003c/p\u003e\n"],["\u003cp\u003eContinuous migration automatically updates data manipulation language (DML) changes, while data definition language (DDL) changes require manual management or the use of \u003ccode\u003epglogical.replicate_ddl_command\u003c/code\u003e to maintain compatibility.\u003c/p\u003e\n"],["\u003cp\u003eCertain components are not migrated, such as unsupported Cloud SQL extensions, large objects, \u003ccode\u003eUPDATE\u003c/code\u003e and \u003ccode\u003eDELETE\u003c/code\u003e statements for tables without primary keys, and data from materialized views, where users will have to refresh it on the destination end.\u003c/p\u003e\n"],["\u003cp\u003eAll data in customized tablespaces will migrate to the default \u003ccode\u003epg_default\u003c/code\u003e tablespace in Cloud SQL, and \u003ccode\u003eSEQUENCE\u003c/code\u003e states may differ from the source to the destination.\u003c/p\u003e\n"]]],[],null,["# Migration fidelity\n\n\u003cbr /\u003e\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 \\| [PostgreSQL to AlloyDB](/database-migration/docs/postgresql-to-alloydb/migration-fidelity \"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\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.\nDuring the migration process, data and constraints are migrated separately. Data is migrated first, and constraints such as primary keys, foreign keys, and indexes are recreated on the instance after the initial full dump and load.\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/postgres/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 `cloudsqlexternalsync` to the Cloud SQL user applying the DDL changes. To enable querying or changing the data, grant the `cloudsqlexternalsync` role to the relevant Cloud SQL 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- To add users to a Cloud SQL destination instance, navigate to the instance and add users\n from the **Users** tab, or add them from a PostgreSQL client. Learn more about [creating\n and managing PostgreSQL users](https://cloud.google.com/sql/docs/postgres/create-manage-users).\n\n- Database Migration Service doesn't migrate [extensions that are unsupported by\n Cloud SQL](/sql/docs/postgres/extensions). The presence of these extensions\n doesn't block the migration, but to ensure a smooth migration process\n verify that your objects or applications don't reference any unsupported\n extensions. We recommend removing these extensions and references from your\n source database before you proceed.\n\n\u003c!-- --\u003e\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."]]