Database Migration Service task stops after full load and does not continue in CDC phase

Question

I am running a Database Migration Service (DMS) task to migrate data from a source database to a target environment. The migration of historical data completes successfully during the initial full load phase, but the task stops progressing once it reaches the Continuous Data Capture (CDC) phase.

The initial data transfer appears to work as expected, and all historical records are migrated successfully. However, after switching to CDC, the task no longer captures or applies ongoing changes from the source database, preventing continuous replication from functioning correctly.

I suspect the issue may be related to the source database binary logging configuration, but I am not sure which settings should be verified or validated for CDC to operate properly.

Could someone advise on how to verify the source database binary logging configuration and identify any prerequisites required for CDC to continue running successfully after the full load phase?

Answer 1

Hello,

The fact that your Database Migration Service task completes the full load but stalls once it enters CDC mode strongly indicates that the source database’s logging configuration is not aligned with the prerequisites for continuous replication. CDC depends entirely on transaction logs or binary logs to capture ongoing changes, and if those logs are not properly enabled or formatted, DMS cannot continue streaming.

If your source is MySQL, you need to confirm that binary logging is enabled (SHOW VARIABLES LIKE 'log_bin'; should return ON). The binlog_format must be set to ROW, not STATEMENT or MIXED, because DMS requires row-based events to replicate changes accurately. Additionally, binlog_row_image should be FULL so that the entire row data is available in the log entries. Without this, partial updates may not be captured correctly. You should also check that the replication user account used by DMS has REPLICATION SLAVE and REPLICATION CLIENT privileges, otherwise it cannot read the binary logs. Finally, verify that log retention is sufficient (expire_logs_days or binlog_expire_logs_seconds) so logs are not purged before DMS processes them.

If your source is SQL Server, CDC must be explicitly enabled on the database and on each table you want to replicate (sys.sp_cdc_enable_db and sys.sp_cdc_enable_table). The SQL Server Agent must be running, since it executes the capture and cleanup jobs. The account used by DMS must have rights to query the CDC tables and access the transaction log. If the Agent is stopped or the CDC jobs are disabled, DMS will not see new changes.

In both cases, the prerequisite is that the source system continuously produces and retains the change logs in the correct format, and that the DMS account has permission to read them. Once you validate and adjust these settings, restart the migration task in CDC mode. If the configuration is correct, you should see new transactions being captured and applied to the target environment without interruption.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

DV.