Ao migrar o esquema, os dados e os metadados de um banco de dados de origem para um
de destino, é importante garantir que todas essas informações sejam
migradas com precisão. O Database Migration Service oferece uma maneira de alta fidelidade de
migrar objetos de banco de dados (incluindo o esquema, os dados e os metadados) de um
banco de dados para outro.
Todos os componentes de dados, esquema e metadados a seguir são migrados como parte
da migração do banco de dados:
Dados
Todas as tabelas de todos os bancos de dados e esquemas, exceto os seguintes:
O esquema de informações information_schema
Qualquer esquema que comece com pg (por exemplo, pg_catalog)
Somente as mudanças na linguagem de manipulação de dados (DML) são atualizadas automaticamente durante
migrações contínuas. O gerenciamento de mudanças na linguagem de definição de dados (DDL) para que os bancos de dados de origem e destino permaneçam compatíveis é responsabilidade do usuário e pode ser feito de duas maneiras:
Interromper as gravações na origem e executar os comandos DDL na origem e no destino. Antes de executar comandos DDL no destino, conceda
alloydbexternalsync ao usuário do AlloyDB que aplica as alterações
DDL. Para ativar consultas ou alterações dos dados, conceda o
papel alloydbexternalsync aos usuários relevantes do AlloyDB.
Use o pglogical.replicate_ddl_command para permitir que a DDL seja executada
na origem e no destino em um ponto consistente. O usuário que executa esse comando precisa ter o mesmo nome de usuário na origem e no destino e ser o superusuário ou o proprietário do artefato que está sendo migrado (por exemplo, a tabela, a sequência, a visualização ou o banco de dados).
Confira alguns exemplos de como usar pglogical.replicate_ddl_command.
Substitua:
[SCHEMA] com o nome do esquema de tabela que você quer usar
[TABLE_NAME] com o nome da tabela
[NEW_NAME_FOR_TABLE] com o novo nome da tabela ao realizar a operação de renomeação
Adicionar uma coluna a uma tabela de banco de dados com uma chave primária
Mudar o nome de uma tabela de banco de dados com uma chave primária
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default}');
Mudar o nome de uma tabela de banco de dados sem uma chave primária
selectpglogical.replicate_ddl_command('ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]','{default_insert_only}');
Criar uma tabela de banco de dados com uma chave primária
Execute os comandos a seguir:
selectpglogical.replicate_ddl_command(command:='CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',replication_sets:=ARRAY['default']);
Criar uma tabela de banco de dados sem uma chave primária
Execute os comandos a seguir:
selectpglogical.replicate_ddl_command(command:='CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',replication_sets:=ARRAY['default_insert_only']);
Objetos grandes
não podem ser replicados, porque o recurso de decodificação lógica do PostgreSQL não oferece suporte
à decodificação de mudanças em objetos grandes. Para tabelas com o tipo de coluna
oid
fazendo referência a objetos grandes, as linhas são sincronizadas e as novas são replicadas.
No entanto, ao tentar acessar o objeto grande no banco de dados de destino
(leitura usando lo_get,
exportação usando lo_export
ou verificação do catálogo pg_largeobject para o oid fornecido), ocorre uma falha com uma mensagem informando que o objeto grande não
existe.
Para tabelas sem chaves primárias, o Database Migration Service oferece suporte à migração de snapshots iniciais e instruções INSERT durante a fase de captura de dados alterados (CDC). Você precisa migrar as instruções UPDATE e DELETE manualmente.
O Database Migration Service não migra dados de visualizações materializadas, apenas o esquema de visualização. Para preencher as visualizações, execute o seguinte comando: REFRESH MATERIALIZED VIEW view_name.
Os estados SEQUENCE (por exemplo, last_value) no novo destino podem variar dos estados SEQUENCE de origem.
Os espaços de tabela personalizados não são aceitos na instância de destino do Cloud SQL. Todos os dados nos espaços de tabela personalizados são migrados para o espaço de tabela pg_default padrão 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-09-03 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."]]