Fidelidade da migração

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Vista geral

Quando migra o esquema, os dados e os metadados de uma base de dados de origem para uma base de dados de destino, quer garantir que todas estas informações são migradas com precisão. O Database Migration Service oferece uma forma de alta fidelidade de migrar objetos de base de dados (incluindo o esquema, os dados e os metadados) de uma base de dados para outra.

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 principais, chaves externas e índices, são recriadas na instância após a descarga e o carregamento completos iniciais.

Todos os seguintes componentes de dados, esquema e metadados são migrados como parte da migração da base de dados:

Dados

• Todas as tabelas de todas as bases de dados e esquemas, excluindo os seguintes esquemas:

  • O esquema de informações information_schema
  • Quaisquer esquemas que comecem por pg (por exemplo, pg_catalog)

  Para mais informações sobre estes esquemas, consulte o artigo Limitações conhecidas.

Esquema

• 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

Metadados

• Procedimentos armazenados

• Funções

• Acionadores

• Visualizações

• Restrições de chaves externas

Migração contínua

Apenas as alterações da linguagem de manipulação de dados (DML) são atualizadas automaticamente durante as migrações contínuas. A gestão das alterações da linguagem de definição de dados (DDL) para que as bases de dados de origem e de destino permaneçam compatíveis é da responsabilidade do utilizador e pode ser feita de duas formas:

1. Parar as escritas na origem e executar os comandos DDL na origem e no destino. Antes de executar comandos DDL no destino, conceda cloudsqlexternalsync 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 cloudsqlexternalsync aos utilizadores relevantes do Cloud SQL.
2. Usando o pglogical.replicate_ddl_command para permitir a execução de 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.

   Substituir:

   • [SCHEMA] com o nome do esquema da tabela que quer usar
   • [TABLE_NAME] com o nome da tabela
   • [NEW_NAME_FOR_TABLE] com o novo nome da tabela quando realizar a operação de mudança de nome

   Adicione uma coluna a uma tabela de base de dados com uma chave principal

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

   Adicione uma coluna a uma tabela de base de dados sem uma chave principal

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

   Altere o nome de uma tabela de base de dados com uma chave principal

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
     '{default}'
   );

   Altere o nome de uma tabela de base de dados sem uma chave principal

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
     '{default_insert_only}'
   );

   Crie uma tabela de base de dados com uma chave principal

   Execute os seguintes comandos:

   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]');

   Crie uma tabela de base de dados sem uma chave primária

   Execute os seguintes comandos:

   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 utilizadores a uma instância de destino do Cloud SQL, navegue até à instância e adicione utilizadores a partir do separador Utilizadores ou adicione-os a partir de um cliente PostgreSQL. Saiba mais sobre como criar e gerir utilizadores do PostgreSQL.

• O Database Migration Service não migra extensões não suportadas pelo Cloud SQL. A presença destas extensões não bloqueia a migração, mas, para garantir um processo de migração sem problemas, verifique se os seus objetos ou aplicações não fazem referência a extensões não suportadas. Recomendamos que remova estas extensões e referências da sua base de dados de origem antes de continuar.

• Não é possível replicar objetos grandes, uma vez que a funcionalidade de descodificação lógica do PostgreSQL não suporta a descodificação de alterações a 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 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) 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 podem variar em relação aos estados SEQUENCE de origem.

• Os espaços de tabelas personalizados não são suportados na instância do Cloud SQL de destino. Todos os dados nos espaços de tabelas personalizados são migrados para o espaço de tabelas pg_default predefinido no Cloud SQL.