Een bedrijf gebruikt AWS DMS om continu wijzigingen vast te leggen vanuit een on-premises PostgreSQL-database en deze te repliceren naar Amazon Redshift. De DMS ongoing replicatietaak leest PostgreSQL-transactielogs, maar de data-engineer constateert een hoge latentie in CDC en vermoedt dat de PostgreSQL-bron de bottleneck is. Welke aanpak zal verifiëren dat de PostgreSQL-database de bron van de latentie is?

De CDCLatencySource-metric in Amazon CloudWatch meet de latentie tussen het moment dat een wijziging plaatsvindt in de brondatabase en het moment dat AWS DMS die wijziging vastlegt. Een hoge waarde voor deze metric duidt direct op een bottleneck aan de bronzijde, wat de vermoedens van de data-engineer bevestigt. Het controleren van CDCIncomingChanges (optie 1) toont het aantal wijzigingen, niet de latentie van de bron. Logische replicatieconfiguratie (optie 2) is een vereiste voor CDC, maar het controleren ervan lost de latentie niet op en identificeert de oorzaak niet. Foutmeldingen in CloudWatch Logs (optie 3) kunnen problemen aangeven, maar de CDCLatencySource-metric is specifieker voor het meten van vertragingen vanuit de bron.