Đã đăng vào about 7 hours ago 6 phút đọc

Amazon Aurora MySQL Bài 34: Xử lý các xung đột dữ liệu và kiểm tra toàn vẹn sau khi Migration

Sau khi đã hoàn thành việc chạy DMS (Full Load + CDC) hoặc sử dụng SCT để chuyển đổi cấu trúc schema sang Aurora MySQL (như đã học ở Bài 32 và 33), nhiều kỹ sư thường có xu hướng thở phào nhẹ nhõm và lập tức trỏ DNS ứng dụng sang hệ thống mới. Tuy nhiên, đây là thời điểm rủi ro nhất nếu hệ thống thiếu đi một khâu cực kỳ quan trọng: Kiểm tra tính toàn vẹn dữ liệu (Data Validation) và xử lý xung đột.

Bài viết này sẽ mổ xẻ các phương pháp kiểm định và giải quyết xung đột dữ liệu chuẩn xác sau khi migration sang Aurora MySQL.

1. Tại sao dữ liệu sau khi Migration vẫn có nguy cơ sai lệch?

Mặc dù các công cụ như AWS DMS hoạt động rất ổn định, việc lệch pha dữ liệu vẫn có thể xảy ra do các nguyên nhân thực tế sau:

Lỗi ràng buộc dữ liệu (Constraint Violations): Một số bản ghi ở cơ sở dữ liệu cũ vi phạm ràng buộc khóa ngoại (Foreign Key) hoặc trùng lặp Unique Index nhưng bị bỏ qua hoặc ghi nhận vào bảng lỗi (Error Table) trong quá trình chuyển đổi.
Độ trễ CDC (Replication Lag): Trong lúc hệ thống cũ vẫn đang mở ghi cho người dùng (Live Traffic), tiến trình CDC có thể chưa đồng bộ kịp một số lượng nhỏ các giao dịch diễn ra sát thời điểm thực hiện Cutover.
Khác biệt về định dạng ký tự (Character Set & Collation): Sự không tương thích giữa các bảng mã (ví dụ từ utf8 sang utf8mb4_unicode_ci) có thể dẫn đến việc cắt cụt ký tự đặc biệt hoặc lỗi hiển thị tiếng Việt có dấu.

2. Các phương pháp kiểm tra tính toàn vẹn dữ liệu (Data Validation Strategies)

Đừng bao giờ tin tưởng tuyệt đối vào kết quả "Migration Completed" trên giao diện quản trị. Hãy chủ động kiểm tra bằng các phương pháp nghiệp vụ sau:

a. Kiểm tra số lượng bản ghi (Row Count Reconciliation)

Phương pháp đơn giản nhất nhưng bắt buộc phải làm là đếm tổng số dòng của từng bảng giữa hệ thống cũ và Aurora MySQL đích:

SQL

-- Chạy trên cả 2 database để so sánh kết quả
SELECT COUNT(*) FROM orders WHERE created_at >= '2026-01-01';

Lưu ý: Cách này chỉ đúng với các bảng tĩnh hoặc các bảng ít thay đổi. Đối với bảng dữ liệu biến động liên tục (như log, giỏ hàng), số lượng dòng sẽ chênh lệch liên tục theo thời gian thực.

b. Kiểm tra mã băm dữ liệu (Checksum Validation)

Để kiểm tra xem nội dung bên trong các dòng dữ liệu có hoàn toàn khớp nhau hay không mà không cần so sánh từng dòng thủ công, ta dùng hàm băm mã hóa (CRC32 hoặc MD5):

SQL

-- Tính tổng mã băm của toàn bộ dữ liệu trong bảng orders
SELECT BIT_XOR(CAST(CRC32(CONCAT_WS('#', id, user_id, status, total_amount)) AS UNSIGNED)) AS checksum 
FROM orders;

Nếu giá trị checksum trả về từ database cũ và Aurora MySQL hoàn toàn khớp nhau, bạn có thể 100% yên tâm rằng dữ liệu bên trong không bị lệch một byte nào.

c. Sử dụng tính năng Data Validation tích hợp sẵn của AWS DMS

AWS DMS cung cấp tính năng Data Validation tự động so sánh dữ liệu giữa nguồn và đích ở cấp độ từng dòng (Row-level validation).
Sau khi hoàn tất migration, bạn có thể xem báo cáo chi tiết của DMS để phát hiện ngay các bảng hoặc dòng nào đang bị trạng thái Mismatched.

3. Xử lý xung đột dữ liệu trong giai đoạn chuyển đổi (Cutover Phase)

Khi hệ thống cũ và Aurora MySQL chạy song song trong vài phút cuối cùng trước khi chuyển đổi DNS, hiện tượng xung đột dữ liệu (Data Conflicts) có thể phát sinh nếu có các thao tác ghi trùng lặp.

Xử lý trùng lặp khóa chính (Primary Key Conflict):
- Nếu hệ thống cũ sử dụng cơ chế tự tăng ID (Auto Increment kiểu 1, 2, 3...) nhưng trong quá trình migration có sự can thiệp ghi dữ liệu nhầm ở cả hai nơi, việc đồng bộ CDC sẽ gây ra lỗi trùng khóa chính (Duplicate entry for primary key).
- Giải pháp: Trước khi chạy Migration, hãy phân tách dải ID rõ ràng hoặc đưa hệ thống cũ về trạng thái Read-only hoàn toàn trước khi cho phép DMS đồng bộ các bước cuối cùng.

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

Chạy thử nghiệm (Dry Run) nhiều lần: Quy trình migration không bao giờ nên thực hiện lần đầu tiên ngay trên môi trường Production. Hãy thực hiện Dry Run ít nhất 2 đến 3 lần trên môi trường Staging với bản sao dữ liệu thực tế để đo lường chính xác thời gian hoàn thành và tìm ra các điểm xung đột tiềm ẩn.
Giữ lại cơ sở dữ liệu cũ trong vài ngày: Sau khi đã trỏ DNS sang Aurora MySQL thành công, tuyệt đối không xóa ngay cơ sở dữ liệu cũ. Hãy giữ lại ở trạng thái Read-only hoặc tắt ghi trong vòng từ 3 đến 7 ngày để phòng hờ trường hợp phát sinh lỗi nghiệp vụ ẩn sâu cần tra cứu lại.

amazon