Sebelum memilih untuk memigrasikan database ke
Cloud SQL, pastikan Anda mempertimbangkan batasan yang diketahui untuk skenario migrasi ini.
Batasan yang diketahui untuk menggunakan database PostgreSQL sebagai sumber meliputi:
Ekstensi pglogical tidak mendukung replikasi kolom yang dihasilkan untuk PostgreSQL 12+.
Perubahan pada struktur tabel (DDL) tidak direplikasi melalui perintah DDL standar, tetapi hanya dengan perintah yang dieksekusi menggunakan ekstensi pglogical yang digunakan untuk replikasi. Ini mencakup
perubahan pada
enum jenis.
Misalnya, pglogical menyediakan fungsi
pglogical.replicate_ddl_command yang memungkinkan DDL dijalankan di
database sumber dan replika pada titik yang konsisten. Pengguna yang menjalankan perintah ini di sumber harus sudah ada di replika.
Untuk mereplikasi data untuk tabel baru, Anda harus menggunakan perintah
pglogical.replication_set_add_table untuk menambahkan
tabel baru ke set replikasi yang ada.
Untuk mempelajari replikasi DDL lebih lanjut saat migrasi sedang
berlangsung, lihat bagian tentang
kualitas migrasi.
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 Cloud SQL baru mungkin berbeda dari status SEQUENCE sumber.
Tabel UNLOGGED dan TEMPORARY tidak dan tidak dapat direplikasi.
Jenis data Large Object tidak didukung. Detail selengkapnya di bagian tentang
akurasi migrasi.
Hanya ekstensi dan bahasa prosedural yang didukung Cloud SQL untuk PostgreSQL yang dapat dimigrasikan.
Database Migration Service tidak memigrasikan ekstensi yang tidak didukung oleh Cloud SQL. Keberadaan ekstensi ini tidak menghalangi migrasi, tetapi untuk memastikan proses migrasi yang lancar, verifikasi bahwa objek atau aplikasi Anda tidak mereferensikan ekstensi yang tidak didukung. Sebaiknya hapus ekstensi dan referensi ini dari database sumber sebelum Anda melanjutkan.
Ekstensi pg_cron (atau setelan cron apa pun yang terkait dengan ekstensi)
tidak dimigrasikan oleh Database Migration Service, tetapi didukung di
tujuan Cloud SQL untuk PostgreSQL. Jika Anda menggunakan ekstensi pg_cron
di database sumber, Anda dapat menginstal ulang ekstensi tersebut di instance tujuan
setelah migrasi selesai.
Database Migration Service tidak mendukung migrasi dari replika baca yang dalam mode pemulihan.
Database Migration Service tidak mendukung sumber Amazon RDS tempat paket ekstensi AWS SCT diterapkan.
Fungsi yang ditentukan pengguna yang ditulis dalam C tidak dapat dimigrasikan, kecuali untuk fungsi yang diinstal dalam database PostgreSQL saat Anda menginstal ekstensi yang didukung oleh Cloud SQL.
Jika ada ekstensi dan bahasa prosedural lain dalam database sumber, atau jika versinya tidak didukung, maka saat Anda menguji atau memulai tugas migrasi, tugas tersebut akan gagal.
Database yang ditambahkan setelah tugas migrasi dimulai tidak akan dimigrasikan.
Anda tidak dapat memilih tabel atau skema tertentu saat melakukan migrasi menggunakan Database Migration Service.
Database Migration Service memigrasikan semua tabel dan skema, kecuali yang berikut:
Skema informasi (information_schema).
Tabel apa pun yang diawali dengan pg, misalnya, pg_catalog. Untuk mengetahui daftar lengkap katalog PostgreSQL yang dimulai dengan pg, lihat Katalog sistem PostgreSQL dalam dokumentasi PostgreSQL.
Informasi tentang pengguna dan peran pengguna tidak dimigrasikan.
Jika database terenkripsi memerlukan kunci enkripsi yang dikelola pelanggan untuk mendekripsi database, dan jika Database Migration Service tidak memiliki akses ke kunci tersebut, database tidak dapat dimigrasikan.
Namun, jika data pelanggan dienkripsi oleh ekstensi pgcrypto, maka data dapat dimigrasikan dengan Database Migration Service (karena Cloud SQL mendukung ekstensi tersebut).
Database Migration Service juga mendukung migrasi data dari database Amazon Aurora atau Amazon RDS terenkripsi karena database ini menangani dekripsi secara transparan di layanannya. Untuk mengetahui informasi selengkapnya, lihat Mengenkripsi resource Amazon Aurora dan Mengenkripsi resource Amazon RDS.
Database Cloud SQL tujuan dapat
ditulis selama migrasi
untuk memungkinkan perubahan DDL diterapkan jika diperlukan. Berhati-hatilah agar tidak membuat perubahan apa pun pada konfigurasi database atau struktur tabel yang dapat mengganggu proses migrasi atau memengaruhi integritas data.
Perilaku pemicu bergantung pada cara pemicu dikonfigurasi. Perilaku defaultnya adalah tidak akan dipicu, tetapi jika dikonfigurasi menggunakan pernyataan
ALTER EVENT TRIGGER atau ALTER TABLE dan status pemicu disetel ke replika atau selalu, maka akan dipicu
pada replika selama replikasi.
Fungsi dengan penentu keamanan akan dibuat oleh
cloudsqlexternalsync di replika Cloud SQL. Saat dijalankan oleh pengguna mana pun, perintah ini akan dijalankan dengan hak istimewa cloudsqlexternalsync yang memiliki peran cloudsqlsuperuser dan cloudsqlreplica. Sebaiknya batasi penggunaan fungsi
penentu keamanan hanya untuk beberapa pengguna. Untuk melakukannya, pengguna harus mencabut hak istimewa PUBLIC default, lalu memberikan hak istimewa eksekusi secara selektif.
Cloud SQL tidak mendukung tablespace yang disesuaikan. Semua data di dalam tablespace yang disesuaikan dimigrasikan ke tablespace pg_default di instance tujuan Cloud SQL.
Metode konektivitas antarmuka Private Service Connect
hanya didukung untuk migrasi ke instance tujuan yang sudah ada.
Jika Anda ingin menggunakan konektivitas IP pribadi dan bermigrasi ke instance tujuan baru, gunakan peering VPC.
Batasan untuk migrasi ke instance tujuan yang ada
Instance tujuan yang ada harus kosong atau hanya berisi
data konfigurasi sistem. Migrasi ke instance tujuan yang sudah ada
yang berisi data pengguna (seperti tabel) tidak didukung.
Jika instance Anda memiliki setelan cadangan yang disesuaikan (misalnya, lokasi cadangan kustom), setelah mempromosikan instance, Anda harus menyesuaikan setelan cadangan lagi. Selama proses promosi, Cloud SQL akan mereset setelan pencadangan Anda ke nilai defaultnya.
Untuk pengguna Terraform: Database Migration Service mengubah setelan pencadangan dan pemulihan instance tujuan Anda. Hal ini dapat menyebabkan
setelan instance tujuan berbeda dengan konfigurasi Terraform
yang Anda gunakan untuk penyediaan. Jika Anda mengalami masalah ini,
ikuti panduan di Mendiagnosis masalah.
Kuota
Hingga 2.000 profil koneksi dan 1.000 tugas migrasi dapat ada kapan saja. Untuk mengosongkan ruang, tugas migrasi (termasuk yang telah selesai) dan profil koneksi dapat dihapus.
[[["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 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."]]
