Quando esegui la migrazione di schema, dati e metadati da un database di origine a un database di destinazione, devi assicurarti che tutte queste informazioni vengano migrate in modo accurato. Database Migration Service offre un modo ad alta fedeltà per eseguire la migrazione degli oggetti di database (inclusi schema, dati e metadati) da un database all'altro.
Durante il processo di migrazione, i dati e le limitazioni vengono migrati separatamente.
Viene eseguita prima la migrazione dei dati e i vincoli come chiavi primarie, chiavi esterne e indici vengono ricreati nell'istanza dopo il dump e il caricamento completi iniziali.
Nell'ambito della migrazione del database viene eseguita la migrazione di tutti i seguenti componenti di dati, schema e metadati:
Dati
Tutte le tabelle di tutti i database e gli schemi, esclusi i seguenti schemi:
Lo schema di informazioni information_schema
Eventuali schemi che iniziano con pg (ad es. pg_catalog)
Per ulteriori informazioni su questi schemi, consulta la sezione Limitazioni note.
Schema
Denominazione
Chiave primaria
Tipo di dati
Posizione ordinale
Valore predefinito
Supporto di valori Null
Attributi con incremento automatico
Indici secondari
Metadati
Stored procedure
Funzioni
Trigger
Visualizzazioni
Vincoli delle chiavi esterne
Migrazione continua
Solo le modifiche data manipulation language (DML) vengono aggiornate automaticamente durante le migrazioni continue. La gestione delle modifiche al linguaggio di definizione dei dati (DDL) in modo che i database di origine e di destinazione rimangano compatibili è responsabilità dell'utente e può essere eseguita in due modi:
Interrompere le scritture sull'origine ed eseguire i comandi DDL sia sull'origine che sulla destinazione. Prima di eseguire i comandi DDL sulla destinazione, concedi
cloudsqlexternalsync all'utente Cloud SQL che applica le modifiche DDL. Per abilitare l'invio di query o la modifica dei dati, concedi il ruolo cloudsqlexternalsync agli utenti Cloud SQL pertinenti.
Utilizza pglogical.replicate_ddl_command per consentire l'esecuzione del DDL su
origine e destinazione in un punto coerente. L'utente che esegue questo
comando deve avere lo stesso nome utente sia nella destinazione sia nell'origine,
e deve essere il superutente o il proprietario dell'elemento di cui viene eseguita la migrazione
(ad esempio la tabella, la sequenza, la vista o il database).
Ecco alcuni esempi di utilizzo di pglogical.replicate_ddl_command.
Sostituisci:
[SCHEMA] con il nome dello schema tabella che vuoi utilizzare
[TABLE_NAME] con il nome della tabella
[NEW_NAME_FOR_TABLE] con il nuovo nome della tabella quando viene eseguita l'operazione di rinominazione
Aggiungere una colonna a una tabella di database con una chiave primaria
Modificare il nome di una tabella di database con una chiave primaria
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default}');
Modificare il nome di una tabella di database senza una chiave primaria
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default_insert_only}');
Crea una tabella di database con una chiave primaria
Esegui questi comandi:
selectpglogical.replicate_ddl_command(command:='CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',replication_sets:=ARRAY['default']);
Creare una tabella di database senza una chiave primaria
Esegui questi comandi:
selectpglogical.replicate_ddl_command(command:='CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',replication_sets:=ARRAY['default_insert_only']);
Per aggiungere utenti a un'istanza di destinazione Cloud SQL, vai all'istanza e aggiungi gli utenti dalla scheda Utenti o da un client PostgreSQL. Scopri di più sulla creazione
e sulla gestione degli utenti 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 agevole
verifica che gli oggetti o le applicazioni non facciano riferimento a estensioni
non supportate. Ti consigliamo di rimuovere queste estensioni e questi riferimenti dal database di origine prima di procedere.
Gli oggetti di grandi dimensioni
non possono essere replicati, poiché la funzionalità di decodifica logica di PostgreSQL non supporta
la decodifica delle modifiche agli oggetti di grandi dimensioni. Per le tabelle con tipo di colonna
oid
che fa riferimento a oggetti di grandi dimensioni, le righe vengono sincronizzate e le nuove righe vengono replicate.
Tuttavia, il tentativo di accedere all'oggetto di grandi dimensioni nel database di destinazione
(lettura utilizzando lo_get,
esportazione utilizzando lo_export,
o controllo del catalogo pg_largeobject per il dato
oid) non va a buon fine e viene visualizzato un messaggio che indica che l'oggetto di grandi dimensioni non esiste.
Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione degli snapshot iniziali e delle istruzioni INSERT durante la fase di acquisizione dei dati modificati (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 delle viste. Per compilare le visualizzazioni, esegui il seguente comando: REFRESH MATERIALIZED VIEW view_name.
Gli stati SEQUENCE (ad es. last_value) nella nuova destinazione potrebbero variare da quelli SEQUENCE di origine.
Gli spazi tabella personalizzati non sono supportati nell'istanza Cloud SQL di destinazione. Tutti i dati all'interno degli spazi tabella personalizzati vengono migrati allo spazio tabella pg_default predefinito in Cloud SQL.
[[["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 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."]]