Solução de problemas do endpoint do PostgreSQL

Esta seção contém cenários de replicação específicos do PostgreSQL.

Transações de execução prolongada na origem

Quando há transações de execução prolongada no banco de dados de origem, como algumas milhares de inserções em uma única transação, os contadores de eventos e transações da CDC do DMS não aumentam até que a transação seja concluída. Esse atraso pode causar problemas de latência que é possível medir utilizando a métrica CDCLatencyTarget.

Para revisar transações de execução prolongada, siga um destes procedimentos:

• Utilize a visualização pg_replication_slots. Se o valor de restart_lsn não estiver sendo atualizado, é provável que o PostgreSQL não possa liberar logs de gravação antecipada (WALs) devido a transações ativas de execução prolongada. Para obter informações sobre a visualização pg_replication_slots, consulte pg_replication_slots na Documentação do PostgreSQL 15.4.

• Utilize a consulta a seguir para retornar uma lista de todas as consultas ativas no banco de dados, junto com as informações relacionadas:

  SELECT pid, age(clock_timestamp(), query_start), usename, query 
  FROM pg_stat_activity WHERE query != '<IDLE>' 
  AND query NOT ILIKE '%pg_stat_activity%'
  ORDER BY query_start desc;

  Nos resultados da consulta, o campo age mostra a duração ativa de cada consulta, que pode ser utilizada para identificar consultas de execução prolongada.

Alta workload na origem

Se o PostgreSQL de origem tiver uma workload alta, verifique o seguinte para reduzir a latência:

• É possível experimentar alta latência ao utilizar o plug-in test_decoding ao migrar um subconjunto de tabelas do banco de dados de origem com um alto valor de transações por segundo (TPS). Isso ocorre porque o plug-in test_decoding envia todas as alterações do banco de dados para a instância de replicação que o DMS filtra com base no mapeamento de tabelas da tarefa. Eventos para tabelas que não fazem parte do mapeamento de tabelas da tarefa podem aumentar a latência da origem.

• Verifique o throughput de TPS utilizando um dos métodos a seguir.

  • Para fontes do Aurora PostgreSQL, use a métrica. CommitThroughput CloudWatch

  • Para o PostgreSQL executado no Amazon RDS ou on-premises, utilize a seguinte consulta com um cliente PSQL versão 11 ou superior (pressione enter durante a consulta para avançar os resultados):

    SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset
    select pg_sleep(60);
    SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset
    select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";
    

• Para reduzir a latência ao utilizar o plug-in test_decoding, considere utilizar o plug-in pglogical em vez disso. Ao contrário do plug-in test_decoding, o plug-in pglogical filtra as alterações do log gravação antecipada (WAL) na origem e envia apenas as alterações relevantes para a instância de replicação. Para obter informações sobre como utilizar o plug-in pglogical com o AWS DMS, consulte Configurar o plug-in pglogical.

Alto throughput de rede

A replicação pode ter alta utilização de largura de banda de rede ao utilizar o plug-in test_decoding, especialmente durante transações de alto volume. Isso ocorre porque o plug-in test_decoding processa as alterações e as converte em um formato legível por humanos que é maior que o formato binário original.

Para melhorar o desempenho, considere utilizar o plug-in pglogical, que é um plug-in binário. Ao contrário do plug-in test_decoding, o plug-in pglogical gera uma saída em formato binário, resultando em alterações do fluxo compactado de log de gravação antecipada (WAL).

Derrame arquivos no Aurora PostgreSQL

No PostgreSQL versão 13 e superior, o parâmetro determina logical_decoding_work_mem a alocação de memória para decodificação e streaming. Para obter mais informações sobre o logical_decoding_work_mem parâmetro, consulte Consumo de recursos no PostgreSQL na documentação do PostgreSQL 13.13.

A replicação lógica acumula alterações em todas as transações na memória até que essas transações sejam confirmadas. Se a quantidade de dados armazenados em todas as transações exceder a quantidade especificada pelo parâmetro do banco de dadoslogical_decoding_work_mem, o DMS transferirá os dados da transação para o disco para liberar memória para novos dados de decodificação.

Transações de longa execução, ou muitas subtransações, podem fazer com que o DMS consuma mais memória de decodificação lógica. Esse aumento no uso de memória faz com que o DMS crie arquivos vazados no disco, o que causa alta latência na fonte durante a replicação.

Para reduzir o impacto de um aumento na carga de trabalho de origem, faça o seguinte:

• Reduza as transações de longa duração.

• Reduza o número de subtransações.

• Evite realizar operações que gerem uma grande quantidade de registros de log, como excluir ou atualizar uma tabela inteira em uma única transação. Em vez disso, execute operações em lotes menores.

Você pode usar as seguintes CloudWatch métricas para monitorar a carga de trabalho na fonte:

• TransactionLogsDiskUsage: o número de bytes atualmente ocupados pelo WAL lógico. Esse valor aumenta monotonicamente se os slots de replicação lógica não conseguirem acompanhar o ritmo de novas gravações ou se alguma transação de longa execução impedir a coleta de lixo de arquivos antigos.

• ReplicationSlotDiskUsage: a quantidade de espaço em disco que os slots de replicação lógica usam atualmente.

Você pode reduzir a latência da fonte ajustando o logical_decoding_work_mem parâmetro. O valor padrão para esse parâmetro é 64 MB. Esse parâmetro limita a quantidade de memória usada por cada conexão lógica de replicação de streaming. Recomendamos definir um logical_decoding_work_mem valor significativamente maior do que o work_mem valor para reduzir a quantidade de alterações decodificadas que o DMS grava no disco.

Recomendamos que você verifique periodicamente se há vazamentos de arquivos, especialmente durante períodos de intensa atividade de migração ou latência. Se o DMS estiver criando um número significativo de arquivos vazados, isso significa que a decodificação lógica não está operando de forma eficiente, o que pode aumentar a latência. Para mitigar isso, aumente o valor do logical_decoding_work_mem parâmetro.

Você pode verificar o estouro atual da transação com a aurora_stat_file função. Para obter mais informações, consulte Como ajustar a memória de trabalho para decodificação lógica no Guia do desenvolvedor do Amazon Relational Database Service.