Database Migration Service é um serviço que facilita a migração de dados para o Google Cloud. O Database Migration Service ajuda a fazer uma migração lift-and-shift das suas cargas de trabalho do PostgreSQL para o Cloud SQL.
O Database Migration Service oferece suporte a migrações do PostgreSQL para o Cloud SQL em qualquer versão
principal, em que o destino seja a mesma versão ou uma versão mais recente do que o banco de dados de origem.
Quais componentes de dados, esquema e metadados são migrados?
O Database Migration Service migra o esquema, os dados e os metadados da origem para o destino. Todos os
componentes de dados, esquema e metadados a seguir são migrados como parte da migração do banco de dados:
Migração de dados
Todos os esquemas e todas as tabelas do banco de dados selecionado.
Migração de esquema
Nomenclatura
Chave primária
Tipo de dado
Posição ordinal
Valor padrão
Nulidade
Atributos de incremento automático
Índices secundários
Migração de metadados
Procedimentos armazenados
Funções
Gatilhos
Visualizações
Restrições de chave externa
Quais mudanças são replicadas durante a migração contínua?
Apenas as mudanças de DML são atualizadas automaticamente durante a migração. O gerenciamento da DDL para que os bancos de dados de origem e de destino permaneçam compatíveis é responsabilidade do usuário e pode ser feito de duas maneiras:
Interrompa as gravações na origem e execute os comandos DDL na origem e no destino. Antes de
executar comandos DDL no destino, conceda o papel cloudsqlexternalsync ao usuário do Cloud SQL que aplica
as alterações DDL. Para ativar consultas ou alterações dos dados, conceda o papel cloudsqlexternalsync aos usuários relevantes do Cloud SQL.
Use pglogical.replicate_ddl_command para executar a DDL 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.
Para adicionar uma coluna a uma tabela de banco de dados, execute o seguinte comando:
Para adicionar usuários à instância de destino do Cloud SQL, navegue até ela e adicione usuários
na guia Usuários ou no cliente do PostgreSQL. Saiba mais sobre como criar
e gerenciar usuários do PostgreSQL.
Objetos grandes não podem ser
replicados porque o recurso de decodificação lógica do PostgreSQL não
oferece suporte a mudanças de decodificação em objetos grandes. Para tabelas com
tipo de coluna oid que referenciam objetos grandes, as linhas ainda são sincronizadas e as novas linhas 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 do Cloud SQL podem variar dos estados SEQUENCE de origem.
Quais métodos de rede são usados?
Para criar uma migração no Database Migration Service, é necessário estabelecer a conectividade entre a origem e a instância de destino do Cloud SQL. Há vários métodos compatíveis.
Escolha a que funciona melhor para a carga de trabalho específica.
Método de rede
Descrição
Prós
Contras
Lista de permissões de IP
Funciona configurando o servidor de banco de dados de origem para aceitar conexões do IP público da instância do Cloud SQL. Se você escolher esse método, o Database Migration Service vai orientar o processo de configuração
durante a criação da migração.
Fácil de configurar.
Recomendado para cenários de migração de curta duração (POC ou pequenas migrações de banco de dados).
A configuração do firewall pode exigir assistência da equipe de TI.
Expõe o banco de dados de origem a um IP público.
A conexão não é criptografada por padrão. É necessário ativar o SSL no banco de dados de origem
para criptografar a conexão.
Túnel SSH reverso por uma VM hospedada na nuvem
Estabelece a conectividade do destino à origem por um túnel SSH reverso seguro.
Requer uma VM Bastion Host no projeto Google Cloud e uma máquina
(por exemplo, um laptop na rede) com conectividade à origem. O Database Migration Service coleta as
informações necessárias no momento da criação da migração e gera automaticamente o script para a configuração.
Fácil de configurar.
Não requer configuração de firewall personalizada.
Recomendado para cenários de migração de curta duração (POC ou pequenas migrações de banco de dados).
Você é proprietário e gerencia a VM Bastion.
Pode gerar custos adicionais.
Peering de VPC
Esse método funciona configurando as VPCs para se comunicarem entre si. Isso só será aplicável se a origem e o destino forem hospedados em Google Cloud. Recomendado para
migrações de longa duração ou de grande volume.
SoluçãoGoogle Cloud .
Fácil de configurar.
Alta largura de banda
Disponível apenas quando a origem está hospedada em Google Cloud.
VPN
Configura um túnel VPN IPSec que conecta a rede interna e a VPC por uma conexão segura pela Internet pública. Google Cloud Use a Google Cloud VPN ou qualquer solução de VPN configurada para a rede interna.
Solução de conectividade robusta e escalonável.
Largura de banda média-alta.
Segurança integrada.
Oferecido como Google Cloud soluções ou de terceiros.
Custo extra.
Configuração não trivial (a menos que já esteja no lugar).
Cloud Interconnect
Usa uma conexão altamente disponível e de baixa latência entre a rede local e
Google Cloud.
Maior largura de banda, ideal para migrações de alto volume de longa duração.
Custo extra.
A conexão não é segura por padrão.
Configuração não trivial (a menos que já esteja no lugar).
[[["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-05 UTC."],[[["\u003cp\u003eDatabase Migration Service simplifies migrating PostgreSQL workloads to Cloud SQL, supporting various source types like Amazon RDS, Aurora, self-managed PostgreSQL, and others.\u003c/p\u003e\n"],["\u003cp\u003eThe service migrates data, schema, and metadata, including schemas, tables, stored procedures, functions, triggers, and views, with DML changes automatically updated during continuous migration.\u003c/p\u003e\n"],["\u003cp\u003ePostgreSQL-to-Cloud SQL migrations are supported across any major version, provided the destination is the same or higher than the source.\u003c/p\u003e\n"],["\u003cp\u003eSeveral networking methods are available, including IP allowlist, reverse SSH tunnel, VPC peering, VPN, and Cloud Interconnect, each with its own set of pros and cons.\u003c/p\u003e\n"],["\u003cp\u003eLarge objects, data from materialized views, and \u003ccode\u003eUPDATE\u003c/code\u003e/\u003ccode\u003eDELETE\u003c/code\u003e statements for tables without primary keys are not migrated by the service.\u003c/p\u003e\n"]]],[],null,["# Database Migration Service for PostgreSQL FAQ\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/faq \"View this page for the MySQL version of Database Migration Service.\") \\| PostgreSQL \\| [PostgreSQL to AlloyDB](/database-migration/docs/postgresql-to-alloydb/faq \"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\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n- [What is Database Migration Service?](#whatisdms)\n- [Which sources are supported?](#sources)\n- [Which destinations are supported?](#destinations)\n- [Is there cross-version support?](#crossversion)\n- [Which data, schema, and metadata components are migrated?](#migrated)\n- [Which changes are replicated during continuous migration?](#replicated)\n- [What isn't migrated?](#notmigrated)\n- [Which networking methods are used?](#networking)\n- [What are the known limitations?](#limitations)\n\n\u003cbr /\u003e\n\nWhat is Database Migration Service?\n: Database Migration Service is a service that makes it easier for you to migrate your data to Google Cloud. Database Migration Service helps you lift and shift your PostgreSQL workloads into Cloud SQL.\n\nWhich sources are supported?\n:\n\n\n - Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17.\n - Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16, 17.\n - Self-managed PostgreSQL (on premises or on any cloud VM that you fully control) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17.\n - Cloud SQL for PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.\n - Microsoft Azure Database for PostgreSQL Flexible Server: 11+\n\n\nWhich destinations are supported?\n:\n\n\n - Cloud SQL for PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.\n\n\nIs there cross-version support?\n:\n\n Database Migration Service supports PostgreSQL-to-Cloud SQL migrations across any major\n version, where the destination is the same or higher version than the source database.\n\nWhich data, schema, and metadata components are migrated?\n\n: Database Migration Service migrates schema, data, and metadata from the source to the destination. All of the following data, schema, and metadata components are migrated as part of the database migration: \u003cbr /\u003e\n\n Data Migration\n\n - All schemas and all tables from the selected database.\n\n Schema Migration\n\n \u003c!-- --\u003e\n\n - Naming\n - Primary key\n - Data type\n - Ordinal position\n - Default value\n - Nullability\n - Auto-increment attributes\n - Secondary indexes\n\n Metadata Migration\n\n \u003c!-- --\u003e\n\n - Stored Procedures\n - Functions\n - Triggers\n - Views\n - Foreign key constraints\n\nWhich changes are replicated during continuous migration?\n:\n\n Only DML changes are automatically updated during the migration. Managing DDL so that the source and\n destination database(s) remain compatible is the responsibility of the user, and can be achieved in\n two ways:\n\n 1. Stop writes to the source and run the DDL commands in both the source and the destination. Before running DDL commands on the destination, grant the `cloudsqlexternalsync` role 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.\n 2. Use the `pglogical.replicate_ddl_command` to run DDL on the source and destination at a consistent\n 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 To add a column to a database table, run the following command:\n\n `select pglogical.replicate_ddl_command('ALTER TABLE `\u003cvar translate=\"no\"\u003e[schema].[table]\u003c/var\u003e` add column surname varchar(20)', '{default}');`\n\n To change the name of a database table, run the following command:\n\n `select pglogical.replicate_ddl_command('ALTER TABLE `\u003cvar translate=\"no\"\u003e[schema].[table]\u003c/var\u003e` RENAME TO `\u003cvar translate=\"no\"\u003e[table_name]\u003c/var\u003e`','{default}');`\n\n To create a database table, run the following commands:\n 1. `select pglogical.replicate_ddl_command(command := 'CREATE TABLE `\u003cvar translate=\"no\"\u003e[schema].[table]\u003c/var\u003e` (id INTEGER PRIMARY KEY, name VARCHAR);', replication_sets := ARRAY['default'']);`\n 2. `select pglogical.replication_set_add_table('default', '`\u003cvar translate=\"no\"\u003e[schema].[table]\u003c/var\u003e`');`\n\nWhat isn't migrated?\n\n: To add users to the Cloud SQL destination instance, navigate to the instance and add users\n from the **Users** tab, or add them from the PostgreSQL client. Learn more about [creating\n and managing PostgreSQL users](https://cloud.google.com/sql/docs/postgres/create-manage-users).\n\n [Large objects](https://www.postgresql.org/docs/current/largeobjects.html) can't be\n replicated because PostgreSQL's logical decoding facility doesn't\n support decoding changes to large objects. For tables that have [column type oid](https://www.postgresql.org/docs/current/datatype-oid.html) referencing large\n objects, the rows are still synced, and new rows are replicated. However, trying to access\n 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), or check\n the catalog `pg_largeobject` for the given oid), fails with a message saying that the large\n object doesn't 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 Cloud SQL destination might vary from the source `SEQUENCE` states.\n\nWhich networking methods are used?\n: To create a migration in Database Migration Service, connectivity must be established\n between the source and the Cloud SQL destination instance. There are a variety of methods supported.\n Choose the one that works best for the specific workload.\n\n\nWhat are the known limitations?\n: See [Known limitations](/database-migration/docs/postgres/known-limitations)."]]
