How CDC Checkpoints Work

AWS DMS tracks its position in the source database’s transaction log so that an interrupted change data capture (CDC) task can resume without replaying everything or skipping anything it has not yet applied. This page covers what is recorded, what that does and does not guarantee, and how to restart replication when a task fails.

What is recorded

Position. DMS periodically records where it has reached in the source’s transaction log. For Oracle that is the SCN (System Change Number); for PostgreSQL, the LSN (Log Sequence Number); for MySQL and MariaDB, the binary log file and position.

Where. Checkpoints are held internally by DMS. They can be read back in two ways: from DescribeReplicationTasks, which returns the latest recovery checkpoint while the task is stopped or failed, and from the awsdms_txn_state table on the target, which DMS writes continuously if the task is created with TaskRecoveryTableEnabled set to Yes. Both are lost when the task is deleted, so a task you may need to recover from should not be deleted casually.

Ordering. Transactions are applied to the target in the order they were committed on the source.

The delivery guarantee

DMS gives at-least-once delivery, not exactly-once. AWS documents several ways duplicates arise:

• Intensive writing to a source table during the full load phase.
• A task configured with TargetTablePrepMode: DO_NOTHING that stops and resumes abruptly during the full load phase.
• A target table with no primary key or unique index, where a repeated row cannot be recognised as a repeat.

Design accordingly: give every replicated table a primary key or unique index, and make anything downstream of the target idempotent. A pipeline built on the assumption that each change arrives exactly once will double-apply rows after the first recovery and will do so silently.

DMS CDC is also not real-time. Latency depends on source workload, network conditions, replication instance capacity, target ingestion rate and the shape of the data, and AWS publishes no latency SLA.

Restarting after a failure

Resume from the last checkpoint

The default and the first thing to try. DMS picks up from where it stopped:

aws dms start-replication-task \
  --replication-task-arn <task-arn> \
  --start-replication-task-type resume-processing

Restart from a chosen position

A task’s CDC start point is set when the task is created and cannot be changed afterwards. AWS’s own guidance is explicit: to use a different CDC start point, create a new task. So the procedure is to stop and (once you are satisfied it is no longer needed) delete the failed task, then create a CDC-only task at the position you want.

From a known SCN:

aws dms create-replication-task \
  --replication-task-identifier oracle-to-pg-recovery-20260910 \
  --source-endpoint-arn <source-endpoint-arn> \
  --target-endpoint-arn <target-endpoint-arn> \
  --replication-instance-arn <replication-instance-arn> \
  --migration-type cdc \
  --table-mappings file://table-mappings.json \
  --replication-task-settings file://task-settings.json \
  --cdc-start-position 6916533

--cdc-start-position takes a bare value in date, checkpoint or LSN/SCN format — a timestamp such as 2026-03-08T12:12:12, a checkpoint string copied from the previous task’s recovery checkpoint, or an engine-native position such as an Oracle SCN or a MySQL mysql-bin-changelog.000024:373. There is no engine-name prefix.

From a point in time, use --cdc-start-time instead; the two are mutually exclusive and supplying both is an error.

aws dms create-replication-task \
  ... \
  --migration-type cdc \
  --cdc-start-time 2026-03-15T14:30:00Z

Note two Oracle-specific caveats. A CDC task started from an SCN or a timestamp misses transactions that were open at that point and committed afterwards; from DMS 3.5.1 the openTransactionWindow endpoint setting lets you specify, in minutes, how far back to scan for them. And PostgreSQL as a source does not support a custom CDC start time at all, because there is no way to map a timestamp to an LSN.

Common recovery problems

Transaction logs have been purged. The position you want is no longer readable on the source. There is no recovery from this other than a fresh full load plus CDC. Prevent it by sizing the source’s log retention for the window you need to be able to go back to, and by monitoring how much history actually remains rather than what the policy says.

A large backlog. DMS has fallen far behind and has millions of changes to work through. Scale up the replication instance, review the change-processing batch settings, and watch CDCLatencySource and CDCLatencyTarget in CloudWatch to see whether the gap is closing.

Intermittent connectivity. Increase the retry settings, use VPC endpoints or a private path rather than the public internet where possible, and check security groups and network ACLs before assuming the failure is in DMS.

DDL on the source. Schema changes can break replication. Decide explicitly how the task should handle DDL, test schema changes in a non-production environment first, and expect to stop and recreate tasks around significant structural changes.

The determining factor in whether CDC can be recovered at all is how long the source keeps its transaction logs. Monitoring that retention, and rehearsing the recovery before it is needed, is worth more than any of the procedures above.