How DMS Moves Data
How DMS Moves Data
AWS Database Migration Service keeps a source and target database synchronized while you plan cutover. Three objects make it work: endpoints (connection details for source and target), a replication instance (a managed EC2-like host in your VPC running the replication), and a task (table mappings plus a mode).
Tasks run full load first — bulk copy of existing rows — then change data capture (CDC), which tails the source's transaction log and applies inserts, updates, and deletes to the target until you cut over. Homogeneous moves (MySQL → MySQL) need no schema work. Heterogeneous moves (Oracle → Aurora PostgreSQL) pair DMS with the Schema Conversion Tool to rewrite schema and code first.
Configuring a Task
Configuring a Task
Placement matters: the replication instance sits in a VPC with network reach to both databases — security groups must allow the traffic, and the same-AZ rule-of-thumb avoids cross-AZ transfer charges. Test each endpoint with the console's connectivity test before starting.
Source access requirements trip people up: MySQL CDC needs binary logging enabled with ROW format; PostgreSQL CDC needs wal_level=logical so DMS can create a replication slot. Most targets also require a primary key on tables for CDC to apply updates and deletes.
At cutover: pause writes, let the task drain remaining changes, flip your application's connection string, then keep the task running briefly as insurance.
Pitfalls and Interview Focus
Pitfalls and Interview Focus
The SCT misconception: it converts schema, stored procedures, and queries — it does not move data, and conversions are often partial (report exactly what it could not convert so you budget manual work). Large LOB columns in CDC mode crawl; most teams use limited LOB handling or migrate them out-of-band.
Operational traps: forgetting CDC requires log access and primary keys; running an undersized replication instance so large tables miss their window; leaving triggers and constraints active on the target slows applies; and stopping the task before final verification, losing the last minutes of change.
Interview: name the three objects (endpoint, instance, task), the two phases (full load, CDC), and one source prerequisite — that answers most DMS questions.
Quiz
1. What does change data capture do during a DMS task?
2. What does the Schema Conversion Tool actually do?
3. Why must PostgreSQL source tables have wal_level=logical for CDC?
Flashcards
Question
DMS three objects
Click to reveal answer
Answer
Endpoint (connections), replication instance (engine in your VPC), task (tables + mode).
Question
Full load vs CDC
Click to reveal answer
Answer
Full load = initial copy; CDC = log-tailing sync for cutover.
Question
SCT role
Click to reveal answer
Answer
Converts heterogeneous schema/procs/queries; does not move data.
Question
CDC prerequisites
Click to reveal answer
Answer
Source log access (binlog ROW / wal_level=logical) and primary keys on target tables.
Question
Cutover sequence
Click to reveal answer
Answer
Pause writes → drain CDC → switch connection string → verify → decommission.
Revision Notes
Key Takeaways
- 1. DMS replicates continuously so cutover is a write pause, not a long outage
- 2. SCT and DMS are complementary: convert first, replicate second
- 3. Log formats and primary keys decide whether CDC works at all
Interview Tips
- • Describe a migration as phases with verification at each: SCT → full load → CDC drain → cutover
- • Mention one CDC prerequisite per engine you know — it shows hands-on experience
Cheat Sheet
DMS = endpoints + replication instance + task; full load then CDC. SCT converts schema (not data). CDC needs binlog ROW / wal_level=logical + PKs. Cutover: pause writes, drain, switch, verify.