Perguntas frequentes sobre o Database Migration Service para PostgreSQL

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

• O que é Database Migration Service?
• Quais origens são compatíveis?
• Quais destinos são aceitos?
• Há suporte para várias versões?
• Quais componentes de dados, esquema e metadados são migrados?
• Quais mudanças são replicadas durante a migração contínua?
• O que não é migrado?
• Quais métodos de rede são usados?
• Quais são as limitações conhecidas?

O que é o Database Migration Service?

O Database Migration Service 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.

Quais fontes são compatíveis?

• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17.
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16 e 17.
• PostgreSQL autogerenciado (no local ou em qualquer VM de nuvem totalmente controlada) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17.
• Cloud SQL para PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.
• Banco de dados Microsoft Azure para PostgreSQL Flexible Server: 11+

Quais destinos são aceitos?

• Cloud SQL para PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.

Há suporte para várias versões?

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
• remotas
• Gatilhos
• Visualizações
• Restrições de chave estrangeira

Quais mudanças são replicadas durante a migração contínua?

Apenas as alterações 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:

1. 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.

2. 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:

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] add column surname varchar(20)', '{default}');

   Para mudar o nome de uma tabela de banco de dados, execute o seguinte comando:

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] RENAME TO [table_name]','{default}');

   Para criar uma tabela de banco de dados, execute os seguintes comandos:

   1. select pglogical.replicate_ddl_command(command := 'CREATE TABLE [schema].[table] (id INTEGER PRIMARY KEY, name VARCHAR);', replication_sets := ARRAY['default'']);
   2. select pglogical.replication_set_add_table('default', '[schema].[table]');

O que não é migrado?

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 opção 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 do 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 nenhuma 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. Isso 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 estiverem hospedados no Google Cloud. Recomendado para migrações de longa duração ou de grande volume.	Solução do Google Cloud . Fácil de configurar. Alta largura de banda	Disponível apenas quando a origem está hospedada no Google Cloud.
VPN	Configura um túnel VPN IPsec que conecta a rede interna e a VPC do Google Cloud por uma conexão segura pela Internet pública. Use o 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 soluções do Google Cloud ou de outras partes.	Custo extra. Configuração não trivial (a menos que já esteja no lugar).
Cloud Interconnect	Usa uma conexão de baixa latência e alta disponibilidade entre a rede local e o 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).

Quais são as limitações conhecidas?

Consulte as limitações conhecidas.