Quais são as práticas recomendadas ao migrar bancos de dados PostgreSQL para um banco de dados RDS para PostgreSQL de destino usando o AWS DMS?

Breve descrição

Ao migrar bancos de dados homogêneos usando o AWS DMS, copie os dados iniciais usando as ferramentas nativas do seu mecanismo, como pg_dump. Em seguida, execute pg_restore no destino. Você também pode usar a replicação lógica e o comando COPY. Para obter mais informações, consulte Práticas recomendadas para migrar bancos de dados PostgreSQL para o Amazon RDS e o Amazon Aurora.

Para migrar de um banco de dados RDS para PostgreSQL para outro banco de dados RDS para PostgreSQL, faça um snapshot e restaure esse snapshot como destino. Para obter mais informações, consulte Migrar um snapshot de uma instância de banco de dados do RDS para PostgreSQL para um cluster de banco de dados Aurora PostgreSQL.

Esteja ciente de que a migração de todos os seus dados de um banco de dados de origem para um de destino usando o carregamento completo do AWS DMS pode ser muito demorada. Você pode ter atrasos devido a fatores como:

• Largura de banda
• Capacidade da origem de enviar grandes quantidades de dados
• Capacidade do mecanismo de replicação de armazenar, processar e encaminhar cargas em massa
• Capacidade do destino de consumir dados da origem

Comparativamente, a replicação de alterações contém apenas alterações da origem para o destino e, portanto, workloads como essa podem ser muito leves.

Criar e determinar o número de sequência de log (LSN) atual

Antes de fazer um backup, você deve usar um marcador para instruir sua tarefa do AWS DMS de que ponto começar a migrar as alterações.

No banco de dados PostgreSQL de origem, execute essas consultas para criar e determinar o LSN atual.

Crie o slot de replicação:

SELECT * FROM
pg_create_logical_replication_slot('replication_slot_name','tset_decoding')

Obtenha o LSN atual:

SELECT restart_LSN  FROM pg_replication_slots WHERE slot_name = 'replication_slot_name';

O comando restart_LSN informa à tarefa do AWS DMS de onde começar a migrar as alterações da origem para o destino.

Resolução

Use essas práticas recomendadas para migrar dados do PostgreSQL para o PostgreSQL usando tarefas do AWS DMS.

Não use chaves estrangeiras e gatilhos durante o carregamento completo

Quando o carregamento completo estiver ocorrendo, certifique-se de que chaves estrangeiras e gatilhos não estejam incluídos na migração. O AWS DMS migra tabelas em ordem alfabética, mas não sabe quais delas são tabelas pai e quais são tabelas filho. Portanto, o AWS DMS pode tentar migrar tabelas filho primeiro. Em seguida, o AWS DMS interrompe a migração das tabelas devido a uma violação de chave estrangeira. Portanto, suprima ou não inclua chaves estrangeiras no destino durante a migração.

Gatilhos nunca devem estar presentes em um destino durante a migração, pois eles executam vários processos que podem corromper os dados no destino. Adicione quaisquer acionadores na substituição.

Ativar o modo de LOB completa ao migrar dados JSON

Ao migrar o LOB no formato JSON, ative o modo de LOB completa para que o formato JSON não fique truncado. Se você usar o modo de LOB limitada, poderá ocorrer truncamento de dados. Em seguida, o AWS DMS garante que a tabela falhe porque o JSON está no formato errado.

Certifique-se de que o campo de chave primária não seja do tipo de dados TEXT

Verifique se o campo de chave primária não é TEXTO, especialmente se o modo de LOB completa estiver ativado. Você poderá obter DUPLICATES de NULLs, pois o AWS DMS trata o tipo de dados TEXT como LOB. Assim, durante o carregamento completo, o AWS DMS tenta tornar a chave primária NULL e, em seguida, relata uma duplicata, pois há muitas colunas de texto com o mesmo valor. O erro nunca é tratado como “NULL not allowed on Primary Key” (Nulo não permitido na chave primária), mas como duplicatas. Esse pode ser um problema difícil de descobrir e resolver. Portanto, sempre confirme que o campo de chave primária não é TEXT para evitar o problema.

Permitir que o AWS DMS crie tabelas de destino

Se o carregamento completo estiver ocorrendo, permita que o AWS DMS crie tabelas no destino. Quando o AWS DMS cria tabelas, ele também cria os campos correspondentes sem valores DEFAULT para as colunas. Valores padrão em colunas podem causar comportamento inesperado no AWS DMS. Por exemplo, SERIAL faz com que a migração do AWS DMS falhe, porque esse campo deseja criar automaticamente um valor. Veja este exemplo:

CREATE TABLE COMPANY (
   ID SERIAL PRIMARY KEY,
   NAME TEXT      NOT NULL);

Se o destino estiver estruturado como esse exemplo, os internos do PostgreSQL desejam gerar o valor da coluna ID. Porém, a origem também contém um valor para INSERT que causa um problema. Portanto, certifique-se de que os DEFAULTS não façam parte do destino durante a migração.

Definir partições como tabelas de origem em mapeamentos de tabelas de tarefas

Ao migrar tabelas particionadas, certifique-se de definir partições como tabelas de origem em mapeamentos de tabelas de tarefas, e não tabelas pai. Isso deve ser feito porque os logs do WAL retêm as informações da tabela particionada. Tabelas pai só devem ser usadas durante o carregamento completo. Portanto, não as use para a fase de CDC. Se você definir tabelas pai durante o CDC, poderá se deparar com erros duplicados que afetarão a migração.

Além disso, ao mapear as tabelas de destino, certifique-se de que todas as partições sejam remapeadas para o pai. Isso significa que o pai é usado para distribuição automática para suas partições.

Defina todas as facetas na fonte ao usar PGLOGICAL

Ao usar PGLOGICAL para migração, certifique-se de definir todas as facetas necessárias na origem. Se você pular uma área, terá um comportamento inesperado. Os problemas que ocorrem como resultado disso são muito difíceis de solucionar. Portanto, verifique se você definiu essas áreas antes de iniciar a migração com PGLOGICAL.

Para o Amazon RDS, defina estes itens:

Grupo de parâmetros:

shared_preload_libraries = pglocical

Nível do banco de dados:

create extension pglogical;

Para On-premises, defina estes itens:

postgresql.conf:

shared_preload_libraries = pglogical

Nível do banco de dados:

create extension pglogical;

Verificar se todos os plug-ins PG definidos na origem estão definidos no destino

Certifique-se de que todos os plug-ins PG definidos na origem também estejam definidos no destino. Isso ajuda na compatibilidade e no processamento harmonioso dos dados.

Verificar se as tarefas não permanecem no estado de parada/erro

Quando as tarefas demoram muito tempo nos estados de parada ou erro, o armazenamento fica lotado no slot de replicação.

Excluir slots de replicação criados manualmente da origem

Se você criou slots de replicação manualmente, exclua-os da origem quando a migração for concluída. Se os slots de replicação permanecerem na origem, eles se acumularão em tamanho, e o armazenamento ficará lotado.

Migrar tabelas com uma chave primária/índice exclusivo

É uma prática recomendada garantir que as tabelas que você está migrando tenham uma chave primária/índice exclusivo. Se uma tabela não tiver uma chave primária, as instruções UPDATE e DELETE talvez não sejam aplicadas à tabela, pois não estão registradas nos logs do WAL. Para tabelas sem uma chave primária, use REPLICATE IDENTITY FULL, mas esteja ciente de que isso gera muitas informações nos logs.

---

Informações relacionadas

Usar um banco de dados PostgreSQL como uma origem do AWS DMS

Destinos para migração de dados