Are you seeing high source latency on an AWS DMS task? We can help you.

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see how our Support Techs assist with this AWS query.

High source latency on an AWS DMS task

 
Usually, you can monitor your AWS DMS task using Amazon CloudWatch metrics.

During a migration, you might see source latency during the ongoing replication phase—change data capture (CDC)—of an AWS DMS task.

Also, you can use the CloudWatch service metric for CDCLatencySource to monitor the source latency for an AWS DMS task.
 

What causes high source latency on an AWS DMS task?

 
If you see source latency on an AWS DMS task, it can be caused by one or more of the following:

• Firstly, the source database has limited resources.
• The AWS DMS replication instance has limited resources.
• The network speed between the source database and the AWS DMS replication instance is slow.
• AWS DMS reads new changes from the transaction logs of the source database during ongoing replication.
• AWS DMS task settings are inadequate or large objects (LOBs) are being migrated.
• The Oracle source database used for the AWS DMS task is using LogMiner for ongoing replication.

How to resolve it?

 
Today, let us see the steps followed by our Support Techs in each case to resolve the issue:
 

The source database has limited resources

 
It is better to use native monitoring for your source DB engine to be sure that your database isn’t experiencing a performance bottleneck.

For example, CPU or memory contention or IO saturation.

The AWS DMS replication instance has limited resources

 
Monitor the replication instance metrics, such as CPUUtilization, FreeStorageSpace, and FreeableMemory.

Then, confirm that the replication instance has enough resources to manage your task.

The network speed between the source database and the AWS DMS replication instance is slow

 
By design, a single AWS DMS task can’t use the full network bandwidth.

If you have a busy production database that has a high rate of changes, then you might need to increase the network bandwidth.

AWS DMS reads new changes from the transaction logs of the source database during ongoing replication

 
Depending on your source DB engine, the source transaction log can also have uncommitted data.

During ongoing replication, AWS DMS reads incoming changes from the transaction logs, but AWS DMS forwards only committed changes to the target.

Eventually, this can result in source latency.

However, when the source database writes a large dataset and executes fewer commits, AWS DMS continues reading from the transaction log.

But AWS DMS doesn’t apply changes the target until the entire transaction is committed, which can also cause source latency.

Because the source latency increases, target latency also increases.

AWS DMS task settings are inadequate or large objects (LOBs) are being migrated

 
AWS DMS migrates LOB data for ongoing replication in two phases.

First, AWS DMS creates a new row in the target table with all columns except those that have LOBs.

Then, AWS DMS updates the rows that have LOBs.

If you have a source database that frequently updates tables that have LOB columns, then you might see source latency.

The Oracle source database used for the AWS DMS task is using LogMiner for ongoing replication

 
If you have a busy source database that generates a large number of redo logs or if the source database is using Oracle Automatic Storage Management (ASM).

You might need to use the binary reader method for ongoing replication.

[Need help with the process? We’d be happy to assist you]

Conclusion

To conclude, here we saw how our Support Techs assist with high source latency on an AWS DMS task.