Perguntas frequentes sobre o Database Migration Service para o AlloyDB

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

• O que é o Database Migration Service?
• Que origens são suportadas?
• Existe compatibilidade entre versões?
• Que componentes de dados, esquema e metadados são migrados?
• Que alterações são replicadas durante a migração contínua?
• O que não é migrado?
• Que métodos de rede são usados?
• Quais são as limitações conhecidas?

O que é o Database Migration Service?

O Database Migration Service é um serviço que facilita a migração dos seus dados para o Google Cloud. O serviço de migração de bases de dados ajuda a migrar as suas cargas de trabalho do PostgreSQL para o AlloyDB.

Que fontes são suportadas?

• 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, 15, 16, 17
• PostgreSQL autogerido (no local ou em qualquer VM na nuvem que controla totalmente) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16 e 17
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16 e 17

Que destinos são suportados?

• AlloyDB para PostgreSQL 14, 15, 16 e 17

Existe suporte entre versões?

O Serviço de migração de bases de dados suporta migrações do PostgreSQL para o AlloyDB a partir de qualquer uma das versões de bases de dados de origem suportadas.

Que componentes de dados, esquema e metadados são migrados?

O serviço de migração de bases de dados migra o esquema, os dados e os metadados da origem para o destino. Todos os seguintes componentes de dados, esquema e metadados são migrados como parte da migração da base de dados:

Migração de dados

• Todos os esquemas e todas as tabelas da base de dados selecionada.

Migração de esquemas

• 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

Migração de metadados

• Procedimentos armazenados
• Funções
• Acionadores
• Visualizações
• Restrições de chaves externas

Que alterações são replicadas durante a migração contínua?

Apenas as alterações de DML são atualizadas automaticamente durante a migração. A gestão da DDL para que as bases de dados de origem e de destino permaneçam compatíveis é da responsabilidade do utilizador e pode ser alcançada de duas formas:

1. Pare as escritas na origem e execute os comandos DDL na origem e no destino. Antes de executar comandos DDL no destino, conceda a função alloydbexternalsync ao utilizador do Cloud SQL 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 Cloud SQL.

2. Use o comando pglogical.replicate_ddl_command para executar 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.

   Para adicionar uma coluna a uma tabela da base de dados, execute o seguinte comando:

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

   Para alterar o nome de uma tabela da base 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 base 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 utilizadores à instância de destino do AlloyDB, adicione-os a partir do cliente PostgreSQL. Saiba mais sobre como criar e gerir utilizadores do PostgreSQL.

Não é possível replicar objetos grandes porque a funcionalidade de descodificação lógica do PostgreSQL não suporta a descodificação de alterações a objetos grandes. Para tabelas que tenham um oid do tipo de coluna que faça referência a objetos grandes, as linhas continuam a ser 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 fornecido) 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 do AlloyDB podem variar em relação aos estados SEQUENCE de origem.

Que métodos de rede são usados?

Para criar uma migração no serviço de migração de base de dados, tem de estabelecer a conetividade entre a origem e a instância de destino do Cloud SQL. São suportados vários métodos. Escolha o que funciona melhor para a carga de trabalho específica.

Método de rede	Descrição	Vantagens	Desvantagens
Túnel SSH inverso através de uma VM alojada na nuvem	Estabelece a conetividade do destino à origem através de um túnel SSH inverso seguro. Requer uma VM de anfitrião de bastião no Google Cloud projeto e uma máquina (por exemplo, um portátil na rede) que tenha conetividade à origem. O serviço de migração de bases de dados recolhe 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 personalizada da firewall. Recomendado para cenários de migração de curta duração (POC ou migrações de bases de dados pequenas).	É proprietário e faz a gestão da VM bastion. Pode incorrer em custos adicionais.
Proxy TCP através de uma VM alojada na nuvem	Estabelece a conetividade do destino à origem através de um proxy TCP através de uma VM alojada na nuvem. O serviço de migração de bases de dados recolhe as informações necessárias no momento da criação da migração e gera automaticamente o script para a configuração. Relevante em migrações do AlloyDB em que a origem está na arquitetura de rede antiga.	Fácil de configurar. Não requer nenhuma configuração personalizada da firewall.	A VM de bastion é detida e gerida por si, e pode incorrer em custos adicionais.
Intercâmbio de VPCs	Este método funciona configurando as VPCs para comunicarem entre si.	Solução Google Cloud nativa. Fácil de configurar. Banda larga Recomendado para migrações de longa duração ou de grande volume.	Só é aplicável se as bases de dados de origem e de destino estiverem alojadas no Google Cloud.
VPN	Configura um canal da VPN IPSec que liga a rede interna e a VPC através de uma ligação segura através da Internet pública. Google Cloud Use Google Cloud uma VPN ou qualquer solução de VPN que esteja configurada para a rede interna.	Solução de conetividade robusta e escalável. Largura de banda média-alta. Segurança integrada. Oferecidos como Google Cloud soluções ou de outros terceiros.	Custo adicional. Configuração não trivial (a menos que já esteja implementada).
Cloud Interconnect	Usa uma ligação de baixa latência e elevada disponibilidade entre a rede no local e Google Cloud.	Largura de banda mais elevada, ideal para migrações de grande volume de longa duração.	Custo adicional. A ligação não é segura por predefinição. Configuração não trivial (a menos que já esteja implementada).

Quais são as limitações conhecidas?

Consulte as limitações conhecidas.