Una empresa utiliza AWS DMS para capturar continuamente los cambios de una base de datos PostgreSQL on-premises y replicarlos en Amazon Redshift. La tarea de replicación continua de DMS lee los registros de transacciones de PostgreSQL, pero el ingeniero de datos observa una alta latencia en CDC y sospecha que la fuente PostgreSQL es el cuello de botella. ¿Qué enfoque verificará que la base de datos PostgreSQL es la fuente de la latencia?

La métrica CDCLatencySource en Amazon CloudWatch es la forma más directa de identificar si la base de datos de origen (PostgreSQL) es la causa de la latencia. Esta métrica mide el tiempo, en segundos, que DMS tarda en leer los cambios desde la base de datos de origen hasta que los procesa internamente. Un valor alto en CDCLatencySource indica que el cuello de botella está en la lectura de los datos desde PostgreSQL. Las otras opciones son incorrectas porque: CDCIncomingChanges mide el número de cambios entrantes, no la latencia. Verificar la configuración de replicación lógica es un paso de configuración inicial, no una herramienta de monitoreo para diagnosticar latencia en tiempo real. Habilitar CloudWatch Logs para buscar errores es útil para depuración general, pero no proporciona una métrica específica de latencia de origen como CDCLatencySource.