Quando migra o esquema, os dados e os metadados de uma base de dados de origem para uma base de dados de destino, quer garantir que todas estas informações são migradas com precisão. O Database Migration Service oferece uma forma de alta fidelidade de migrar objetos de base de dados (incluindo o esquema, os dados e os metadados) de uma base de dados para outra.
Todos os seguintes componentes de dados, esquema e metadados são migrados como parte
da migração da base de dados:
Dados
Todas as tabelas de todas as bases de dados e esquemas, excluindo os seguintes esquemas:
O esquema de informações information_schema
Quaisquer esquemas que comecem por pg (por exemplo, pg_catalog)
Para mais informações sobre estes esquemas, consulte o artigo Limitações conhecidas.
Esquema
Atribuição de nomes
Chave principal
Tipo de dados
Posição ordinal
Valor predefinido
Condição de nulidade
Atributos de incremento automático
Índices secundários
Metadados
Procedimentos armazenados
Funções
Acionadores
Visualizações
Restrições de chaves externas
Migração contínua
Apenas as alterações da linguagem de manipulação de dados (DML) são atualizadas automaticamente durante as migrações contínuas. A gestão das alterações da linguagem de definição de dados (DDL) para que as bases de dados de origem e de destino permaneçam compatíveis é da responsabilidade do utilizador e pode ser feita de duas formas:
Parar as escritas na origem e executar os comandos DDL na origem e no destino. Antes de executar comandos DDL no destino, conceda
alloydbexternalsync ao utilizador do AlloyDB que aplica as alterações
DDL. Para ativar a consulta ou a alteração dos dados, conceda a função alloydbexternalsync aos utilizadores relevantes do AlloyDB.
Usando o pglogical.replicate_ddl_command para permitir a execução de DDL na origem e no destino num ponto consistente. O utilizador que executa este comando tem de ter o mesmo nome de utilizador na origem e no destino e deve ser o superutilizador ou o proprietário do artefacto que está a ser migrado (por exemplo, a tabela, a sequência, a vista ou a base de dados).
Seguem-se alguns exemplos de utilização do ícone pglogical.replicate_ddl_command.
Substituir:
[SCHEMA] com o nome do esquema da tabela que quer usar
[TABLE_NAME] com o nome da tabela
[NEW_NAME_FOR_TABLE] com o novo nome da tabela quando realizar a operação de mudança de nome
Adicione uma coluna a uma tabela de base de dados com uma chave principal
Altere o nome de uma tabela de base de dados com uma chave principal
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default}');
Altere o nome de uma tabela de base de dados sem uma chave principal
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default_insert_only}');
Crie uma tabela de base de dados com uma chave principal
Execute os seguintes comandos:
selectpglogical.replicate_ddl_command(command:='CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',replication_sets:=ARRAY['default']);
Crie uma tabela de base de dados sem uma chave primária
Execute os seguintes comandos:
selectpglogical.replicate_ddl_command(command:='CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',replication_sets:=ARRAY['default_insert_only']);
Não é possível replicar objetos grandes, uma vez que a funcionalidade de descodificação lógica do PostgreSQL não suporta a descodificação de alterações a objetos grandes. Para tabelas com o tipo de coluna
oid
que referenciam objetos grandes, as linhas são sincronizadas e as novas linhas são replicadas.
No entanto, tentar aceder ao objeto grande na base de dados de destino (ler através de lo_get, exportar através de lo_export ou verificar o catálogo pg_largeobject para o oid) falha com uma mensagem a indicar que o objeto grande não existe.
Para tabelas que não têm chaves principais, o Database Migration Service suporta a migração da imagem instantânea inicial e das declarações INSERT durante a fase de captura de dados de alterações (CDC). Deve migrar as declarações UPDATE e DELETE manualmente.
O Database Migration Service não migra dados de vistas materializadas, apenas o esquema de vistas. Para preencher as vistas, execute o seguinte comando: REFRESH MATERIALIZED VIEW view_name.
Os estados SEQUENCE (por exemplo, last_value) no novo destino podem variar em relação aos estados SEQUENCE de origem.
Os espaços de tabelas personalizados não são suportados na instância do Cloud SQL de destino. Todos os dados nos espaços de tabelas personalizados são migrados para o espaço de tabelas pg_default predefinido no Cloud SQL.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-21 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."]]