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á.
Esta seção contém cenários de replicação específicos do PostgreSQL.
Tópicos
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 orestart_lsnvalor não estiver sendo atualizado, é provável que o PostgreSQL não consiga liberar Write Ahead Logs WALs () devido a transações ativas de longa duração. Para obter informações sobre a visualizaçãopg_replication_slots, consulte pg_replication_slotsna 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
agemostra 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_decodingao 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-intest_decodingenvia 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.
CommitThroughputCloudWatchPara o PostgreSQL executado no Amazon RDS ou on-premises, utilize a seguinte consulta com um cliente PSQL versão 11 ou superior (pressione
enterdurante 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-inpglogicalem vez disso. Ao contrário do plug-intest_decoding, o plug-inpglogicalfiltra 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 usar opglogicalplug-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 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).
Arquivos de despejo no Aurora PostgreSQL
Na versão 13 e superior do PostgreSQL, o parâmetro logical_decoding_work_mem determina a alocação de memória para decodificação e streaming. Para ter mais informações sobre o parâmetro logical_decoding_work_mem, consulte Resource Consumption in PostgreSQL
A replicação lógica acumula alterações de 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 logical_decoding_work_mem do banco de dados, o DMS despejará os dados da transação para o disco e irá 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 da memória faz com que o DMS crie arquivos de despejo no disco, o que causa alta latência na origem durante a replicação.
Para reduzir o impacto de um aumento na workload de origem, faça o seguinte:
Reduza as transações de longa execução.
Reduza o número de subtransações.
Evite realizar operações que gerem uma grande quantidade de logs, 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 resíduos 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 na origem ajustando o parâmetro logical_decoding_work_mem. O valor padrão desse 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 valor de logical_decoding_work_mem significativamente maior do que o valor de work_mem para reduzir a quantidade de alterações decodificadas que o DMS grava no disco.
Recomendamos que você verifique os arquivos de despejo periodicamente, em especial durante períodos de intensa atividade de migração ou latência. Se o DMS estiver criando um número significativo de arquivos de despejo, 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 parâmetro logical_decoding_work_mem.
Você pode verificar o estouro atual da transação com a função aurora_stat_file. Para ter mais informações, consulte Ajustar a memória de trabalho para decodificação lógica no Guia do desenvolvedor do Amazon Relational Database Service.
