Fidelidade de migração

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Visão geral

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.

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

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

1. Interromper as gravações na origem e executar 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 alterações DDL. Para ativar consultas ou alterações dos dados, conceda o papel cloudsqlexternalsync aos usuários relevantes do Cloud SQL.
2. 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

   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é ela e adicione os 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 têm suporte do Cloud SQL. A presença dessas extensões não bloqueia a migração, mas, para garantir um processo de migração tranquilo, verifique se os 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 prosseguir.

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