Prima di scegliere di eseguire la migrazione dei database a
Cloud SQL, assicurati di prendere in considerazione le limitazioni note per questo scenario di migrazione.
Le limitazioni note per l'utilizzo di un database PostgreSQL come origine includono:
L'estensione pglogical non supporta la replica delle colonne generate per PostgreSQL 12 e versioni successive.
Le modifiche alle strutture delle tabelle (DDL) non vengono replicate tramite i comandi DDL standard, ma solo con i comandi eseguiti utilizzando l'estensione pglogical utilizzata per la replica. Ciò include
modifiche ai
tipi di enum.
Ad esempio, pglogical fornisce una funzione
pglogical.replicate_ddl_command che consente l'esecuzione del DDL sia sul database di origine sia sulla replica in un punto coerente. L'utente
che esegue questo comando sull'origine deve già esistere sulla replica.
Per replicare i dati per le nuove tabelle, devi utilizzare il
comando pglogical.replication_set_add_table per aggiungere
le nuove tabelle ai set di replica esistenti.
Per saperne di più sulla replica DDL durante la migrazione, consulta la sezione relativa alla fedeltà della migrazione.
Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione degli snapshot iniziali e delle istruzioni INSERT durante la fase Change Data Capture (CDC). Devi eseguire manualmente la migrazione delle istruzioni UPDATE e DELETE.
Database Migration Service non esegue la migrazione dei dati dalle viste materializzate, ma solo dello schema della vista. Per popolare le visualizzazioni, esegui il comando seguente: REFRESH MATERIALIZED VIEW view_name.
Gli stati SEQUENCE (ad esempio last_value) nella nuova destinazione Cloud SQL potrebbero variare rispetto agli stati SEQUENCE dell'origine.
Le tabelle UNLOGGED e TEMPORARY non vengono replicate e non possono essere replicate.
Possono essere migrate solo le estensioni e i linguaggi procedurali
che Cloud SQL supporta per PostgreSQL.
Database Migration Service non esegue la migrazione delle estensioni non supportate da
Cloud SQL. La presenza di queste estensioni non blocca la migrazione,
ma per garantire un processo di migrazione senza problemi verifica che i tuoi oggetti o
applicazioni non facciano riferimento a estensioni non supportate. Ti consigliamo di rimuovere
queste estensioni e questi riferimenti dal database di origine prima di
procedere.
L'estensione pg_cron (o qualsiasi impostazione cron associata all'estensione) non viene migrata da Database Migration Service, ma è supportata nelle destinazioni Cloud SQL per PostgreSQL. Se utilizzi l'estensione pg_cron nei database di origine, puoi reinstallarla nell'istanza di destinazione al termine della migrazione.
Database Migration Service non supporta la migrazione dalle repliche di lettura in modalità di recupero.
Database Migration Service non supporta le origini Amazon RDS a cui è applicato il pacchetto di estensioni AWS SCT.
Le funzioni definite dall'utente scritte in C non possono essere migrate, ad eccezione di quelle installate nel database PostgreSQL quando installi le estensioni supportate da Cloud SQL.
Se nel database di origine esistono altre estensioni e linguaggi procedurali o se le loro versioni non sono supportate, il test o l'avvio del job di migrazione non andrà a buon fine.
I database aggiunti dopo l'avvio del job di migrazione non vengono migrati.
Non puoi selezionare tabelle o schemi specifici quando esegui la migrazione utilizzando Database Migration Service.
Database Migration Service esegue la migrazione di tutte le tabelle e gli schemi, ad eccezione di quanto segue:
Lo schema di informazioni (information_schema).
Qualsiasi tabella che inizia con pg, ad esempio pg_catalog. Per l'elenco completo dei cataloghi PostgreSQL che iniziano con pg, consulta la sezione Cataloghi di sistema PostgreSQL nella documentazione di PostgreSQL.
Le informazioni sugli utenti e sui ruoli utente non vengono migrate.
Se i database criptati richiedono chiavi di crittografia gestite dal cliente per essere decriptati e se Database Migration Service non ha accesso alle chiavi, i database non possono essere migrati.
Tuttavia, se i dati dei clienti sono criptati dall'estensione pgcrypto, possono essere migrati con Database Migration Service (perché Cloud SQL supporta l'estensione).
Database Migration Service supporta anche la migrazione dei dati da database Amazon Aurora o Amazon RDS criptati perché questi database gestiscono la decrittografia in modo trasparente nei loro servizi. Per ulteriori informazioni, vedi Crittografia delle risorse Amazon Aurora e Crittografia delle risorse Amazon RDS.
Il database Cloud SQL di destinazione è scrivibile durante la migrazione per consentire l'applicazione delle modifiche DDL, se necessario. Fai attenzione a non apportare modifiche alla configurazione del database o alle strutture delle tabelle che potrebbero interrompere la procedura di migrazione o influire sull'integrità dei dati.
Il comportamento dei trigger dipende dalla loro configurazione. Il comportamento predefinito è che non vengono attivati, ma se sono stati configurati utilizzando l'istruzione ALTER EVENT TRIGGER o ALTER TABLE e lo stato del trigger è impostato su replica o sempre, vengono attivati sulla replica durante la replica.
Le funzioni con definizioni di sicurezza verranno create da
cloudsqlexternalsync nella replica Cloud SQL. Quando viene
eseguito da qualsiasi utente, viene eseguito con i privilegi di
cloudsqlexternalsync che ha i ruoli cloudsqlsuperuser e
cloudsqlreplica. È preferibile limitare l'utilizzo di una funzione di definizione della sicurezza solo ad alcuni utenti. A questo scopo, l'utente deve revocare i privilegi PUBLIC predefiniti e poi concedere il privilegio di esecuzione in modo selettivo.
Cloud SQL non supporta i tablespace personalizzati. Tutti i dati all'interno degli spazi delle tabelle personalizzati vengono migrati nello spazio delle tabelle pg_default nell'istanza di destinazione Cloud SQL.
Il
metodo di connettività delle interfacce Private Service Connect è supportato solo per la migrazione alle istanze di destinazione esistenti.
Se vuoi utilizzare la connettività IP privata ed eseguire la migrazione a una nuova istanza di destinazione, utilizza il peering VPC.
Limitazioni per le migrazioni alle istanze di destinazione esistenti
L'istanza di destinazione esistente deve essere vuota o contenere solo
dati di configurazione del sistema. La migrazione a istanze di destinazione esistenti
che contengono dati utente (ad esempio tabelle) non è supportata.
Se la tua istanza ha impostazioni di backup personalizzate (ad esempio una posizione di backup personalizzata), dopo averla promossa, devi personalizzare nuovamente le impostazioni di backup. Durante il processo di promozione, Cloud SQL reimposta le impostazioni di backup ai valori predefiniti.
Per gli utenti di Terraform: Database Migration Service modifica le impostazioni di backup
e ripristino dell'istanza di destinazione. Ciò potrebbe comportare
che le impostazioni dell'istanza di destinazione siano diverse dalla configurazione Terraform
utilizzata per il provisioning. Se riscontri questo problema,
segui le indicazioni riportate in Diagnostica dei problemi.
Quote
In qualsiasi momento, possono esistere fino a 2000 profili di connessione e 1000 job di migrazione. Per creare spazio, è possibile eliminare i job di migrazione (compresi quelli completati) e i profili di connessione.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
