Skip to content
advanced Phase 14 · AWS Migration

Database Migration Service

Migrate databases with AWS DMS and Schema Conversion Tool.

1h
0 problems
Topic Progress 0%

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?

Question 1 options

2. What does the Schema Conversion Tool actually do?

Question 2 options

3. Why must PostgreSQL source tables have wal_level=logical for CDC?

Question 3 options

Flashcards

Question

DMS three objects

Answer

Endpoint (connections), replication instance (engine in your VPC), task (tables + mode).

Question

Full load vs CDC

Answer

Full load = initial copy; CDC = log-tailing sync for cutover.

Question

SCT role

Answer

Converts heterogeneous schema/procs/queries; does not move data.

Question

CDC prerequisites

Answer

Source log access (binlog ROW / wal_level=logical) and primary keys on target tables.

Question

Cutover sequence

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.

Continue Learning