Como soluciono problemas de replicação lógica em um cluster de banco de dados de origem compatível com o PostgreSQL do Aurora?

Resolução

Configure parâmetros de replicação

Antes de solucionar problemas de replicação lógica, configure os seguintes parâmetros em seu grupo de parâmetros de cluster de banco de dados:

• Defina o valor de rds.logical_replication como 1 para ativar a replicação lógica em seu cluster de banco de dados.
• Defina um valor para max_replication_slots que inclua slots suficientes para a contagem esperada de assinaturas e processos adicionais de sincronização de tabelas.
• Defina max_wal_senders como um valor que suporte sua cota de max_replication_slots e suas réplicas físicas atuais.
• Defina max_logical_replication_workers como um valor que suporte sua contagem de assinaturas e o número de processamentos adicionais que o sistema de replicação exige para sincronização de tabelas.
• Defina max_worker_processes como um valor que seja pelo menos um a mais do que o valor de max_logical_replication_workers. Por exemplo, se max_logical_replication_workers for 25, defina max_worker_processes como 26.
• Se a cópia de dados estiver lenta, aumente o valor de max_sync_workers_per_subscription para controlar o número de processamentos de sincronização que processam a configuração da assinatura e as novas adições de tabela.

Importante: para aplicar as alterações anteriores, você deve reinicializar seu cluster de banco de dados compatível com o PostgreSQL do Aurora.

Verifique a configuração de publicação e assinatura

Depois de configurar os parâmetros de replicação lógica, verifique se você configurou corretamente as publicações e assinaturas. Certifique-se de que a publicação inclui todas as tabelas pretendidas, se os parâmetros de assinatura estão corretos e se o usuário da replicação tem as permissões apropriadas.

Conecte-se ao seu banco de dados de origem e execute os seguintes comandos:

Para verificar a configuração da sua publicação, execute os seguintes comandos:

SELECT * FROM pg_publication;
SELECT * FROM pg_publication_tables;

Para verificar a configuração da sua assinatura, execute os seguintes comandos:

SELECT * FROM pg_subscription;
SELECT * FROM pg_subscription_rel;

Confirme se os slots de replicação estão ativos

Conecte-se ao seu banco de dados de origem e execute o seguinte comando:

SELECT slot_name, plugin, slot_type, active, restart_lsn,
       confirmed_flush_lsn, pg_current_wal_lsn(),
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots;

Se os slots estiverem inativos ou apresentarem atraso excessivo, analise os processamentos de replicação para solucionar o problema.

Confirme se os processamentos de replicação estão ativos

Conecte-se ao seu banco de dados de destino e execute o seguinte comando:

SELECT pid, state, query, wait_event, backend_type
FROM pg_stat_activity
WHERE backend_type LIKE 'logical replication%';

Se não houver processamentos de replicação, reinicie sua assinatura.

Para desativar sua assinatura, execute o seguinte comando:

ALTER SUBSCRIPTION subscription_name DISABLE;

Para ativar sua assinatura, execute o seguinte comando:

ALTER SUBSCRIPTION subscription_name ENABLE;

Se ainda não houver processamentos de replicação depois que você reiniciar a assinatura, verifique se há mensagens de erro nos logs de erros do PostgreSQL.

Monitore o progresso e o atraso da replicação

Sua replicação pode apresentar atraso devido ao alto volume de transações e às grandes transações na publicação. Ou pode haver restrições na publicação ou assinatura.

Para identificar se a replicação foi interrompida ou está lenta, monitore o progresso da replicação por alguns intervalos.

Conecte-se ao seu cluster de banco de dados e execute os seguintes comandos.

Para verificar o progresso da replicação da sua publicação, execute o seguinte comando:

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag,
       active
FROM pg_replication_slots
WHERE slot_type = 'logical';

Para verificar o progresso da replicação da sua assinatura, execute o seguinte comando:

SELECT subname, pid, received_lsn, latest_end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, received_lsn)) AS lag
FROM pg_stat_subscription;

Para minimizar o atraso na replicação, monitore o cache write-through. Se o tamanho do cache não for suficiente para seus workloads, é possível alterar manualmente o valor de rds.logical_wal_cache. Para obter mais informações, consulte Achieve up to 17x lower replication lag with the new write-through cache for Aurora PostgreSQL (Alcance um atraso de replicação até 17 vezes menor com o novo cache write-through no Aurora PostgreSQL).

Monitore as restrições de recursos

Para solucionar as restrições de recursos no publicador e no assinante, ative o Monitoramento aprimorado e monitore CPUUtilization, FreeableMemory, SwapUsage e NetworkThroughput. Configure os alarmes do Amazon CloudWatch para serem notificados quando ocorrerem problemas de replicação.

Para obter mais informações, consulte Como identifico e soluciono problemas de desempenho e consultas de execução lenta em minha instância de banco de dados do Amazon RDS para PostgreSQL ou compatível do Aurora PostgreSQL?

Identifique incompatibilidades de esquema e resolva inconsistências de dados

Conecte-se ao seu banco de dados de origem e ao banco de dados de destino. Em seguida, confirme se há colunas nas tabelas replicadas e se os tipos de dados são compatíveis. Além disso, certifique-se de que as chaves primárias e as restrições exclusivas sejam consistentes.

Para ativar sua assinatura, execute o seguinte comando:

ALTER SUBSCRIPTION subscription_name ENABLE;

Para comparar as definições de tabela, execute o seguinte comando nos dois bancos de dados:

SELECT column_name, data_type, character_maximum_length
FROM information_schema.columns
WHERE table_name = 'your_table_name'
ORDER BY ordinal_position;

Observação: substitua your_table_name pelo nome da sua tabela.

Resolva conflitos

A replicação lógica nativa do PostgreSQL não consegue detectar conflitos de dados de vários publicadores ou modificações replicadas que entrem em conflito com os dados que você alterou localmente. Se houver uma linha atual com a mesma chave, o Aurora aplica a atualização e a inserção falha.

Para identificar o que causou o conflito, verifique os logs do PostgreSQL.

O exemplo de log a seguir mostra que a replicação falhou porque ela tentou inserir um registro com um ID de ativo que já existe no banco de dados de destino:

ERROR: 23505: duplicate key value violates unique constraint "asset_pkey"
DETAIL: Key (asset_id)=(7) already exists.
CONTEXT: processing remote data for replication origin "pg_32796" during message type "INSERT" for replication target relation "public.asset" in transaction 315434, finished at 0/6A12458

A origem da replicação é pg_32796 e termina no Número de sequência lógica (Logical Sequence Number, LSN) 0/6A12458.

Para corrigir manualmente os dados, é possível interromper a replicação no conflito ou configurar a assinatura com a opção disable_on_error.

Ou é possível consultar os dados na origem e no destino para verificar se é possível ignorar o LSN que causou o conflito. Em seguida, use a função pg_replication_origin_advance() para pular o LSN que causou o conflito. Para obter mais informações, consulte pg_replication_origin_advance (node_name text, lsn pg_lsn) no site do PostgreSQL.

Observação: as versões 15 e posteriores compatíveis com o PostgreSQL do Aurora oferecem suporte à função pg_replication_origin_advance().

Para pular o LSN, conclua as seguintes etapas:

1. Execute o seguinte comando SQL para desativar temporariamente a assinatura:

   ALTER SUBSCRIPTION subscription_name DISABLE;

   Observação: se você configurou a assinatura com a opção disable_on_error, a assinatura é desativada automaticamente após um erro.

2. Use a seguinte função pg_replication_origin_advance() para avançar a origem até Finish_LSN+1:

   SELECT pg_replication_origin_advance('node_name','Finish_LSN+1'::pg_lsn);

   Observação: substitua node_name pelo nome do seu nó.

3. Execute o comando a seguir para ativar a assinatura:

   ALTER SUBSCRIPTION subscription-name ENABLE;

   Observação: substitua subscription-name pelo nome da sua assinatura.

Para resolver várias inconsistências de dados, talvez seja necessário limpar a tabela de destino e reconfigurar a publicação e a assinatura.

Informações relacionadas

Replicação com Amazon Aurora PostgreSQL

PostgreSQL Logical Replication (Replicação lógica do PostgreSQL) no site do PostgreSQL

Configurar a replicação lógica para seu cluster de banco de dados do Aurora PostgreSQL

Monitorar métricas do Amazon Aurora com o Amazon CloudWatch