Uma empresa usa o AWS DMS para capturar continuamente as alterações de um banco de dados PostgreSQL on-premises e replicá-las para o Amazon Redshift. A tarefa de replicação contínua do DMS lê os logs de transação do PostgreSQL, mas o engenheiro de dados observa alta latência no CDC e suspeita que a origem PostgreSQL seja o gargalo. Qual abordagem verificará se o banco de dados PostgreSQL é a origem da latência?

A métrica CDCLatencySource no Amazon CloudWatch é a forma mais direta de identificar se o gargalo de latência está na origem PostgreSQL. Ela mede o tempo, em segundos, entre a transação ser confirmada no banco de dados de origem e o AWS DMS capturar essa transação. Uma latência alta nesta métrica indica que o banco de dados de origem não está fornecendo as alterações ao DMS de forma eficiente. A opção de verificar CDCIncomingChanges não é a ideal porque essa métrica mostra o número de alterações recebidas, não o atraso na captura das alterações da origem. Habilitar o CloudWatch Logs para o endpoint do DMS pode ajudar a diagnosticar erros, mas não mede diretamente a latência da origem. Verificar a configuração de replicação lógica no postgresql.conf é uma etapa de configuração inicial importante, mas não é uma métrica de monitoramento contínuo para identificar latência em tempo real.