Đã đăng vào khoảng 7 giờ trước 5 phút đọc

Amazon Aurora MySQL Bài 32: Chiến lược Migration dữ liệu không gián đoạn từ MySQL truyền thống sang Aurora MySQL

Khi công ty quyết định nâng cấp hệ thống từ cơ sở dữ liệu MySQL truyền thống (chạy trên EC2, RDS MySQL tiêu chuẩn, hoặc On-Premise) lên Amazon Aurora MySQL để tận dụng hiệu năng vượt trội và kiến trúc phân tán, bài toán lớn nhất đặt ra cho đội ngũ kỹ thuật là: Làm sao để di chuyển hàng trăm GB dữ liệu mà hệ thống backend KHÔNG PHẢI DOWNTIME (hoặc downtime dưới vài giây)?

Bài viết này sẽ mổ xẻ chiến lược migration không gián đoạn sử dụng mô hình kết hợp AWS DMS (Database Migration Service) và cơ chế CDC (Change Data Capture).

1. Sai lầm kinh điển: "Dump & Restore" truyền thống

Cách làm thủ công mà nhiều kỹ sư thiếu kinh nghiệm hay dùng khi migration:

Bật chế độ bảo trì ứng dụng (Maintenance Mode).
Chạy lệnh mysqldump xuất toàn bộ dữ liệu từ database cũ ra tệp.
Import tệp đó vào cụm Aurora MySQL mới.
Trỏ DNS ứng dụng sang Aurora và tắt Maintenance Mode.

Hậu quả: Với các cơ sở dữ liệu lớn (vài trăm GB đến hàng TB), quá trình dump và import có thể kéo dài từ vài tiếng đến nửa ngày. Trong suốt thời gian đó, hệ thống website/app bị tê liệt hoàn toàn, gây thiệt hại nghiêm trọng về doanh thu và trải nghiệm người dùng. Phương pháp này tuyệt đối cấm kỵ đối với các hệ thống Production lớn.

2. Chiến lược chuẩn Enterprise: Full Load kết hợp CDC (Replication)

Để migration không gián đoạn, chúng ta chia quá trình thành 2 giai đoạn cốt lõi: Full Load (Đưa dữ liệu lịch sử sang) và CDC - Change Data Capture (Đồng bộ liên tục các thay đổi phát sinh theo thời gian thực).

AWS cung cấp dịch vụ chuyên dụng cho bài toán này là AWS DMS (Database Migration Service) hoặc bạn có thể tự dựng bằng các công cụ mã nguồn mở như Debezium kết hợp Apache Kafka.

Giai đoạn 1: Full Load (Sao chép dữ liệu tĩnh ban đầu)

AWS DMS kết nối đồng thời tới nguồn (MySQL cũ) và đích (Aurora MySQL).
Nó tiến hành đọc và sao chép toàn bộ các bảng dữ liệu lịch sử hiện có sang Aurora mà không khóa bảng (Non-blocking), ứng dụng vẫn đọc/ghi bình thường ở cơ sở dữ liệu cũ.
Trong lúc Full Load đang diễn ra, người dùng vẫn đang thao tác tạo đơn hàng mới, dẫn đến việc dữ liệu ở nguồn liên tục thay đổi. Để xử lý việc này, AWS DMS kích hoạt một tiến trình ghi nhận log gọi là Task Pre-load Capture.

Giai đoạn 2: CDC - Change Data Capture (Đồng bộ thời gian thực)

Ngay sau khi Full Load hoàn tất, AWS DMS chuyển sang chế độ CDC.
Nó liên tục đọc tệp Binlog (Binary Log) từ database cũ, dịch nghĩa các câu lệnh INSERT, UPDATE, DELETE mới phát sinh và thực hiện "phát lại" (replay) các thay đổi đó lên Aurora MySQL.
Độ trễ đồng bộ (Replication Lag) trong giai đoạn này thường chỉ vỏn vẹn vài giây, giúp dữ liệu trên Aurora đuổi kịp sát nút với cơ sở dữ liệu cũ.

3. Quy trình cắt chuyển (Cutover Window) không gián đoạn thực tế

Khi dữ liệu giữa hai bên đã đồng bộ hoàn toàn (Replication Lag về gần bằng 0), đây là thời điểm vàng để thực hiện Cutover với thời gian downtime tính bằng giây:

Chuyển ứng dụng sang trạng thái Read-only ngắn ngủi (Tùy chọn): Hoặc giữ nguyên nếu bạn cấu hình định tuyến nhanh.
Cập nhật DNS hoặc Endpoint: Thay đổi cấu hình chuỗi kết nối (DSN) trong biến môi trường của ứng dụng backend (.env) từ địa chỉ MySQL cũ sang Cluster Endpoint của Aurora MySQL. (Nếu bạn sử dụng AWS RDS Proxy, bạn chỉ cần trỏ proxy sang Aurora trước đó).
Kiểm tra và Xác nhận: Kiểm tra log ứng dụng, đảm bảo các request mới đã ghi thẳng vào Aurora MySQL thành công.
Tắt nguồn Database cũ: Hoàn tất quá trình migration an toàn tuyệt đối mà người dùng cuối không hề cảm nhận được sự gián đoạn nào.

4. Góc nhìn vận hành cho Backend Engineer

Kiểm tra tính tương thích của phiên bản (Schema Compatibility): Trước khi chạy DMS, hãy đảm bảo phiên bản MySQL nguồn và Aurora MySQL đích tương thích nhau (ví dụ migrate từ MySQL 5.7 lên Aurora MySQL 3 tương thích MySQL 8.0). Sử dụng công cụ AWS Schema Conversion Tool (SCT) nếu có sự chuyển đổi khác biệt về engine hoặc kiểu dữ liệu.
Xử lý khóa ngoại (Foreign Keys): Trong quá trình Full Load, nên tạm thời vô hiệu hóa các ràng buộc khóa ngoại (FOREIGN_KEY_CHECKS = 0) để DMS đổ dữ liệu vào các bảng con và bảng cha không bị vướng lỗi thứ tự, sau đó bật lại khi hoàn tất.

amazon