</>Học Dev
Bài học

Tuần 2 - Ngày 3: AWS DMS - Database Migration Service

Tuần 2 – Ngày 3

Mục tiêu học tập

  • Hiểu kiến trúc DMS: replication instance, endpoints, tasks
  • Phân biệt full load, CDC, full load + CDC
  • Biết vai trò SCT (Schema Conversion Tool) và DMS Serverless
  • Dùng DMS đưa dữ liệu database vào S3 data lake (ingestion pattern)

1. DMS là gì

AWS DMS replicate dữ liệu giữa các database/data store: on-premises ↔ AWS, DB ↔ S3/Kinesis... Nguồn giữ hoạt động bình thường trong khi migrate (minimal downtime).

┌──────────┐┌─────────────────────────┐┌──────────────┐│SOURCE│────►│ReplicationInstance│────►│TARGET││Oracle,││(EC2doDMSquảnlý,││RDS,Aurora,││MySQL,││chạyreplicationtask)││Redshift,S3,││SQLSrv,││hoặcDMSServerless││Kinesis,││Postgres,│└─────────────────────────┘│DynamoDB,││MongoDB..│source&targetENDPOINTS│OpenSearch...│└──────────┘└──────────────┘

Ba loại task

LoạiHành viUse case
Full loadCopy toàn bộ dữ liệu hiện cóMigrate một lần, chấp nhận freeze
CDC onlyChỉ stream thay đổi (đọc transaction log: binlog/WAL/redo log)Nguồn đã được load sẵn cách khác
Full load + CDCLoad toàn bộ rồi tiếp tục stream thay đổiMigrate không downtime — phổ biến nhất

CDC (Change Data Capture) đọc log giao dịch của nguồn nên gần như không ảnh hưởng workload nguồn (yêu cầu bật binlog/logical replication ở nguồn).

2. DMS cho Data Engineering — DB → Data Lake

Pattern DEA quan trọng: replicate liên tục database vận hành vào S3:

RDS/on-premDB──DMS(fullload+CDC)──►S3rawzone(CSV/Parquet,kèmcộtOp:I/U/D)│GlueETLmerge/dedupe▼curatedzone/Icebergtable
  • Target S3 ghi được Parquet trực tiếp (DataFormat=parquet) — tiết kiệm bước convert
  • File CDC chứa cột Op (Insert/Update/Delete) + timestamp → downstream phải áp logic merge (vd MERGE INTO Iceberg) để có trạng thái mới nhất
  • Muốn stream thay đổi realtime cho consumer khác: target Kinesis Data Streams

3. Schema Conversion Tool (SCT)

  • DMS di chuyển dữ liệu, không chuyển đổi schema giữa engine khác loại.
  • SCT convert schema + code (stored procedures, functions) giữa engine khác nhau: Oracle → Aurora PostgreSQL, SQL Server → Aurora MySQL, Teradata/Netezza → Redshift (data warehouse migration)
  • Homogeneous (MySQL → Aurora MySQL): không cần SCT (dùng native dump hoặc DMS thẳng)
  • Heterogeneous (Oracle → PostgreSQL): SCT trước (schema), DMS sau (data)
  • SCT còn có data extraction agents cho warehouse lớn (kết hợp Snowball khi network hạn chế)

4. DMS Serverless và các tính năng vận hành

  • DMS Serverless: không chọn instance class — khai báo min/max DCU, DMS tự scale; phù hợp khi không muốn capacity planning ("least operational overhead")
  • Multi-AZ replication instance: standby đồng bộ cho production migration
  • Table mappings + transformation rules (JSON): chọn schema/table (include/exclude), đổi tên, filter cột
  • Validation: DMS data validation so sánh source-target
  • Migration lớn/mạng yếu: SCT + AWS Snowball Edge chuyển full load offline, DMS CDC bù phần thay đổi sau

5. Chọn công cụ ingestion database — so sánh

Nhu cầuCông cụ
Replicate DB liên tục (CDC) vào lake/warehouseDMS
Copy một lần bảng JDBC vào S3, transform luônGlue job (JDBC source)
Aurora/RDS → Redshift không codeZero-ETL integration (Aurora MySQL/PostgreSQL, RDS MySQL → Redshift)
Migrate schema Oracle → AuroraSCT (rồi DMS cho data)
File server/NFS → S3DataSync (bài sau)

Zero-ETL đáng nhớ: tích hợp managed, dữ liệu từ Aurora xuất hiện trong Redshift sau vài giây, không cần dựng pipeline DMS/Glue — đáp án "least operational overhead" cho analytics trên dữ liệu transactional.

Câu hỏi ôn tập

  1. Migrate database production sang AWS với downtime tối thiểu — dùng loại task DMS nào?

    Xem đáp án

    Full load + CDC: DMS copy toàn bộ dữ liệu hiện có, đồng thời capture thay đổi phát sinh trong lúc load (đọc transaction log), sau đó áp tiếp các thay đổi cho đến khi target đuổi kịp — cutover chỉ vài phút. Full load thuần sẽ mất các ghi mới trong lúc copy; CDC only thiếu dữ liệu lịch sử.

  2. Migrate Oracle sang Aurora PostgreSQL cần những công cụ nào, thứ tự?

    Xem đáp án

    Heterogeneous migration: (1) AWS SCT convert schema, PL/SQL, objects sang PostgreSQL — báo cáo phần phải sửa tay; (2) AWS DMS (full load + CDC) di chuyển dữ liệu. DMS không tự convert schema giữa engine khác loại nên thiếu SCT là sai.

  3. DMS ghi CDC vào S3 — downstream cần chú ý gì để có trạng thái dữ liệu mới nhất?

    Xem đáp án

    File CDC là chuỗi sự kiện I/U/D (cột Op), không phải snapshot. Downstream phải merge: lấy bản ghi mới nhất theo khóa + timestamp, áp delete. Cách hiện đại: MERGE INTO bảng Iceberg bằng Glue/Athena; hoặc job dedupe theo window. Ghi Parquet ngay từ DMS (DataFormat=parquet) để đỡ bước convert.

  4. Khi nào chọn DMS Serverless thay vì replication instance?

    Xem đáp án

    Khi không muốn capacity planning: workload thay đổi/không dự đoán, hoặc team muốn "least operational overhead". Khai báo min/max DCU, DMS tự scale. Replication instance phù hợp khi cần kiểm soát chi tiết (instance class, một số engine/tính năng chỉ có trên instance) hoặc workload ổn định dài hạn có thể tối ưu chi phí.

  5. Cần dữ liệu từ Aurora MySQL có mặt trong Redshift cho BI trong vài giây, không muốn vận hành pipeline. Giải pháp?

    Xem đáp án

    Zero-ETL integration Aurora → Redshift — AWS tự replicate liên tục vào Redshift (managed), độ trễ giây, không dựng DMS/Glue. Đây là đáp án "near real-time + least operational overhead". DMS + Redshift target cũng chạy được nhưng phải tự vận hành task/instance.

Bài tập thực hành

  • Vẽ lại diagram pipeline DMS full load + CDC từ RDS MySQL → S3 → Glue merge → Iceberg
  • Trong lab (nếu có RDS): tạo DMS replication instance nhỏ + task full load một bảng sang S3, xem file output và cột Op
  • Đọc table mapping JSON: viết rule chỉ include schema sales, exclude bảng audit_%
  • Đọc Zero-ETL integrations

Tài liệu tham khảo chính thức

Tiếp theo: DataSync và Transfer Family