Un'azienda utilizza AWS DMS per acquisire continuamente le modifiche da un database PostgreSQL on-premises e replicarle su Amazon Redshift. Il task di replica continua di DMS legge i log delle transazioni di PostgreSQL, ma l'ingegnere dei dati osserva un'elevata latenza nel CDC e sospetta che la sorgente PostgreSQL sia il collo di bottiglia. Quale approccio verificherà che il database PostgreSQL sia la causa della latenza?

La metrica CDCLatencySource in Amazon CloudWatch è specificamente progettata per misurare il ritardo tra il momento in cui una modifica viene commessa sul database di origine e il momento in cui DMS la acquisisce. Un valore elevato per questa metrica indica che il database PostgreSQL di origine non sta fornendo le modifiche a DMS abbastanza velocemente, confermando che l'origine è il collo di bottiglia. Le altre opzioni sono meno efficaci: CDCIncomingChanges misura il numero di modifiche acquisite da DMS, non la latenza. Verificare la configurazione della replica logica è un passo di risoluzione dei problemi, ma non diagnostica direttamente la latenza. Abilitare i log di CloudWatch per l'endpoint di origine può mostrare errori, ma non quantifica la latenza di acquisizione dal database di origine.