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 endpoint do PostgreSQL
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL"></a>

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

**Topics**
+ [Transações de execução prolongada na origem](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning)
+ [Alta workload na origem](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload)
+ [Alto throughput de rede](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork)
+ [Arquivos de despejo no Aurora PostgreSQL](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)

## Transações de execução prolongada na origem
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning"></a>

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 `restart_lsn` valor 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ção `pg_replication_slots`, consulte [pg\$1replication\$1slots](https://www.postgresql.org/docs/15/view-pg-replication-slots.html) na [Documentação do PostgreSQL 15.4](https://www.postgresql.org/docs/15/).
+ 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
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload"></a>

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 usar o `pglogical` plug-in com AWS DMS, consulte[Configurar o plug-in pglogical](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.Pglogical).

## Alto throughput de rede
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork"></a>

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
<a name="CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill"></a>

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](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM) na [documentação do PostgreSQL 13.13](https://www.postgresql.org/docs/13/).

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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem) no *Guia do desenvolvedor do Amazon Relational Database Service*.