Fidelidade de migração

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Visão geral

Ao migrar seu esquema, dados e metadados de um banco de dados de origem para um de destino, é importante garantir que todas essas informações sejam migradas com precisão. Com o Database Migration Service, é possível realizar migrações de alta fidelidade de objetos de banco de dados, incluindo esquemas, dados e metadados, de um banco de dados para outro.

Durante o processo de migração, os dados e as restrições são migrados separadamente. Os dados são migrados primeiro, e as restrições, como chaves primárias, chaves estrangeiras e índices, são recriadas na instância após o despejo e o carregamento completos iniciais.

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 esquemas:

  • O esquema de informações information_schema
  • Qualquer esquema que comece com pg (por exemplo, pg_catalog)

  Para mais informações sobre esses esquemas, consulte Limitações conhecidas.

Esquema

• Nomenclatura

• Chave primária

• Tipo de dado

• Posição ordinal

• Valor padrão

• Nulidade

• Atributos de incremento automático

• Índices secundários

Metadados

• Procedimentos armazenados

• Funções

• Gatilhos

• Visualizações

• Restrições de chave externa

Migração contínua

Somente as mudanças na linguagem de manipulação de dados (DML) são atualizadas automaticamente durante as migrações contínuas. O gerenciamento das mudanças na linguagem de definição de dados (DDL) para que os bancos de dados de origem e destino permaneçam compatíveis é de responsabilidade do usuário e pode ser feito de duas maneiras:

1. Interrompendo as gravações na origem e executando os comandos DDL na origem e no destino. Antes de executar comandos DDL no destino, conceda cloudsqlexternalsync ao usuário do Cloud SQL que aplica as mudanças DDL. Para ativar consultas ou alterações dos dados, conceda o papel cloudsqlexternalsync aos usuários relevantes do Cloud SQL.
2. Usando 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 precisa 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 o 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

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

   Adicionar uma coluna a uma tabela de banco de dados sem uma chave primária

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] add column surname varchar(20)',
     '{default_insert_only}'
   );

   Mudar o nome de uma tabela de banco de dados com uma chave primária

   select pglogical.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

   select pglogical.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:

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

   2. select pglogical.replication_set_add_table('default', '[SCHEMA].[TABLE_NAME]');

   Criar uma tabela de banco de dados sem uma chave primária

   Execute os comandos a seguir:

   1. select pglogical.replicate_ddl_command(
        command := 'CREATE TABLE [SCHEMA].[TABLE_NAME]
         (id INTEGER PRIMARY KEY, name VARCHAR);',
        replication_sets := ARRAY['default_insert_only']
      );

   2. select pglogical.replication_set_add_table(
        'default_insert_only', '[SCHEMA].[TABLE_NAME]'
      );

O que não é migrado

• Para adicionar usuários a uma instância de destino do Cloud SQL, navegue até a instância e adicione usuários na guia Usuários ou em um cliente PostgreSQL. Saiba mais sobre como criar e gerenciar usuários do PostgreSQL.

• O Database Migration Service não migra extensões que não são compatíveis com o Cloud SQL. A presença dessas extensões não bloqueia a migração, mas para garantir um processo tranquilo, verifique se seus objetos ou aplicativos não fazem referência a extensões sem suporte. Recomendamos remover essas extensões e referências do banco de dados de origem antes de continuar.

• Objetos grandes não podem ser replicados porque o recurso de decodificação lógica do PostgreSQL não é compatível com a decodificação de mudanças em 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 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 específico) 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 do snapshot inicial e das instruções INSERT durante a fase de captura de dados alterados (CDC). Migre 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 em relação aos estados SEQUENCE de origem.

• Os espaços de tabela personalizados não são compatíveis com a instância de destino do Cloud SQL. Todos os dados dentro dos espaços de tabela personalizados são migrados para o espaço de tabela padrão pg_default no Cloud SQL.