- Newest
- Most votes
- Most comments
The first thing I would check is the DMS cloudwatch logs which will clarify where the DMS task is waiting for the one which takes hours. DMS also creates some control tables on the target database which hold useful information about the replication state and status. Those tables are stored in dmslogs schema. You mentioned that the two databases support two different applications from same vendor. If those apps are different is it possible one apps is more heavily used than the other and correspondingly the underlying database for the same is more active and generate more changes than the other ? data volume can be a factor for replication lag. DMS latest version is supposed to be more performant than previous so I don't think version would be a problem unless you are hitting any bug which will show up in cloudwatch log. Anyway pls confirm the DMS version here and reply back.
Relevant content
- asked 6 months ago
- asked 2 years ago
- asked 10 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 2 years ago
Thanks for your response. DMS version is 3.5.1. You make a good point about data volume but I observe this difference even in development systems where the data volume is extremely low for both applications.
I have done a cursory review of logs and one difference I see is: in the faster database, the "initial load" of tables (I forgot to mention this is a CDC-only load, and I don't understand why it starts with an initial load of 0 rows for every table) has each subtask go on to the next table when it is finished with the table it is working on, whereas in the slower database it seems to wait for all subtasks to complete before going on to the next set of tables.