Solução de problemas do Postgre SQL Endpoint - AWS Database Migration Service
Transações de execução prolongada na origemAlta workload na origemAlto throughput de redeDerrame arquivos no Aurora Postgre SQL

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solução de problemas do Postgre SQL Endpoint

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

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

Quando há transações de longa duração no banco de dados de origem, como alguns milhares de inserções em uma única transação, os contadores de DMS CDC eventos e transações 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 restart_lsn valor não estiver sendo atualizado, é provável que o Postgre SQL não consiga liberar Write Ahead Logs (WALs) devido a transações ativas de longa duração. Para obter informações sobre a pg_replication_slots visualização, consulte pg_replication_slots na documentação do Postgre 15.4. SQL

  • 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 Postgre de origem SQL tiver uma carga de trabalho alta, verifique o seguinte para reduzir a latência:

  • Você pode experimentar alta latência ao usar o test_decoding plug-in 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 test_decoding plug-in envia todas as alterações do banco de dados para a instância de replicação, que DMS então filtra, com base no mapeamento da tabela da tarefa. Eventos para tabelas que não fazem parte do mapeamento de tabelas da tarefa podem aumentar a latência da origem.

  • Verifique a TPS taxa de transferência usando um dos métodos a seguir.

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

    • Para o Postgre SQL executado na Amazon RDS ou no local, use a seguinte consulta usando uma versão 11 ou superior do PSQL cliente (pressione enter durante a consulta para avançar nos 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 test_decoding plug-in, o pglogical plug-in filtra as alterações de registro antecipado (WAL) na origem e envia apenas as alterações relevantes para a instância de replicação. Para obter informações sobre como usar o pglogical plug-in com AWS DMS, consulteConfigurar o plug-in pglogical.

Alto throughput de rede

A replicação pode ter alta utilização de largura de banda da 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 test_decoding plug-in, o pglogical plug-in gera uma saída em formato binário, resultando em alterações de stream compactadas de write ahead log (WAL).

Derrame arquivos no Aurora Postgre SQL

Na SQL versão 13 e superior do Postgre, o logical_decoding_work_mem parâmetro determina 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 Postgre SQL na documentação do Postgre SQL 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, os dados da transação serão DMS transferidos para o disco para liberar memória para novos dados de decodificação.

Transações de longa execução, ou muitas subtransações, podem resultar no DMS consumo de maior memória de decodificação lógica. Esse aumento no uso de memória resulta na DMS criação de 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 lógicoWAL. 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 são DMS gravadas 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 DMS estiver criando um número significativo de arquivos de vazamento, 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.