Giới thiệu

Khi doanh nghiệp phát triển, nhu cầu mở rộng và tối ưu cơ sở hạ tầng trở nên quan trọng. Trong bối cảnh đó, việc migrate dữ liệu từ cloud khác sang AWS là một bước đi chiến lược giúp tối ưu hóa hiệu suất, tận dụng sức mạnh của hệ sinh thái AWS, và tiết kiệm chi phí dài hạn. Vừa qua, tôi đã thực hiện một quá trình migrate hơn 200 triệu bản ghi từ một hệ thống cơ sở dữ liệu đám mây khác lên AWS bằng công cụ AWS Database Migration Service (DMS). Trong bài viết này, tôi sẽ chia sẻ cách mà tôi đã thực hiện dự án này, các thách thức đã gặp và những bài học rút ra trong quá trình di chuyển dữ liệu.

1. Chuẩn bị môi trường và yêu cầu ban đầu

Môi trường hiện tại: Dữ liệu của tôi được đặt trên một cơ sở dữ liệu MySQL, lưu trữ trong một dịch vụ đám mây khác. Hệ thống này đã được vận hành trong một thời gian dài và lượng dữ liệu liên tục tăng lên, đặc biệt với các bảng có tới hàng triệu bản ghi.

Thiết lập AWS: Trước khi bắt đầu quá trình migrate, tôi đã chuẩn bị hạ tầng trên AWS với các dịch vụ cần thiết:

• EC2 Instance cho việc lưu trữ (DB Mysql đích).
• VPC và Security Group để bảo mật kết nối giữa các dịch vụ.
• IAM Role để thiết lập quyền truy cập giữa các dịch vụ AWS và DMS.

Chuẩn bị dữ liệu: Trước khi bắt đầu migrate, tôi đã kiểm tra cấu trúc của các bảng, các schema và kiểu dữ liệu để đảm bảo rằng chúng tương thích với cơ sở dữ liệu trên AWS. Điều này đặc biệt quan trọng vì việc không khớp kiểu dữ liệu có thể dẫn đến lỗi trong quá trình di chuyển.

2. Cấu hình cơ sở dữ liệu nguồn

Để quá trình migrate diễn ra mượt mà, việc cấu hình đúng MySQL trên cơ sở dữ liệu nguồn là rất quan trọng. Dưới đây là các bước tôi đã thực hiện để chuẩn bị môi trường nguồn:

Bước 1: Dump cấu trúc cơ sở dữ liệu

Trước khi bắt đầu migrate, tôi đã dump cấu trúc của cơ sở dữ liệu nguồn và nhập vào cơ sở dữ liệu đích trên EC2. Điều này giúp đảm bảo rằng các bảng trên hệ thống mới sẽ tương thích với dữ liệu được di chuyển từ hệ thống cũ.

mysqldump -h <source-host> -u <user> -p --no-data <db_name> > structure.sql​

Sau đó, tôi đã import file này trên DB server đích để tạo bảng trước khi bắt đầu migrate dữ liệu.

Giải thích lý do phải dump cấu trúc cơ sở dữ liệu của bảng nguồn

Trong quá trình migrate dữ liệu từ cloud khác lên AWS bằng AWS DMS, việc dump cấu trúc cơ sở dữ liệu (schema) từ bảng nguồn là một bước quan trọng, vì AWS DMS có một số hạn chế khi xử lý cấu trúc phức tạp của cơ sở dữ liệu. Dưới đây là một số lý do cụ thể:

1. DMS không hỗ trợ partitioning
   Nếu bảng trong cơ sở dữ liệu nguồn có sử dụng partitioning (phân vùng dữ liệu), AWS DMS sẽ không hỗ trợ việc di chuyển trực tiếp cấu trúc phân vùng này. Điều này có thể dẫn đến việc mất thông tin về phân vùng khi migrate. Để đảm bảo cấu trúc phân vùng được bảo toàn, chúng ta cần dump cấu trúc và tự tạo lại các phân vùng đó trên cơ sở dữ liệu đích trước khi migrate dữ liệu.

   Ví dụ:
   Nếu bạn có bảng sử dụng phân vùng để quản lý dữ liệu theo ngày hoặc ID, việc dump cấu trúc trước sẽ giúp bạn giữ nguyên thiết lập này khi nhập lại trên cơ sở dữ liệu RDS của AWS.

2. Tối ưu hóa quá trình di chuyển
   Khi bạn dump và import cấu trúc bảng trước (chỉ bao gồm schema, không bao gồm dữ liệu), nó giúp giảm thời gian cần thiết cho AWS DMS trong việc tạo lại cấu trúc bảng trên đích. Điều này đặc biệt hữu ích với những bảng lớn và phức tạp, vì nó giúp tập trung tài nguyên vào việc di chuyển dữ liệu thay vì phải xử lý cả cấu trúc.

3. Tránh lỗi không tương thích cấu trúc
   AWS DMS có thể gặp khó khăn trong việc xử lý các bảng với các index hoặc constraints đặc biệt, hoặc những tính năng nâng cao khác của MySQL mà DMS chưa hỗ trợ hoàn toàn. Bằng cách dump schema trước, bạn có thể điều chỉnh lại cấu trúc theo cách thủ công, đảm bảo cơ sở dữ liệu đích trên RDS tương thích hoàn toàn trước khi bắt đầu migrate dữ liệu.

4. Kiểm soát tốt hơn về cấu trúc
   Việc dump schema và áp dụng nó một cách thủ công trên cơ sở dữ liệu đích cho phép bạn kiểm soát tốt hơn toàn bộ quá trình. Bạn có thể xem xét kỹ càng và tùy chỉnh cấu trúc theo nhu cầu của hệ thống đích, từ đó tối ưu hóa hiệu suất và đảm bảo tính toàn vẹn dữ liệu.

Bước 2: Tạo user MySQL với quyền truy cập từ xa

Để cho phép AWS DMS truy cập vào cơ sở dữ liệu, tôi đã tạo một user MySQL cho cả 2 nguồn, và đích với quyền truy cập từ bất kỳ địa chỉ IP nào. Điều này đặc biệt quan trọng khi cơ sở dữ liệu của bạn được lưu trữ trong một cloud khác và cần cấp quyền truy cập từ AWS.

CREATE USER 'puser'@'%' IDENTIFIED BY 'Vwe2hKv59xLiids';
GRANT ALL PRIVILEGES ON *.* TO 'puser'@'%' WITH GRANT OPTION;

Lý do: Việc tạo user với quyền truy cập từ xa giúp DMS có thể kết nối tới cơ sở dữ liệu nguồn, đích di chuyển dữ liệu mà không gặp vấn đề về quyền hạn hay bảo mật. User này cần có đủ quyền để đọc và ghi dữ liệu trong suốt quá trình migration.

Bước 3: Cấu hình MySQL source

Tôi đã chỉnh sửa file cấu hình /etc/my.cnf trên MySQL nguồn để tối ưu quá trình migration. Dưới đây là các tùy chọn quan trọng mà tôi đã thêm:

net_read_timeout=6000
net_write_timeout=6000
wait_timeout=6000
expire_logs_days=7
local_infile=1
server_id=1
log_bin=/var/log/mysql/mysql-bin.log
max_binlog_size=100M
binlog_format=ROW​

• net_read_timeout / net_write_timeout: Tăng thời gian chờ cho các hoạt động đọc/ghi giữa MySQL và DMS, tránh mất kết nối khi lượng dữ liệu lớn.
• wait_timeout: Giữ kết nối với cơ sở dữ liệu lâu hơn để tránh việc kết nối bị đóng trong quá trình migrate kéo dài.
• expire_logs_days: Đặt thời gian lưu trữ logs binlog, giúp quản lý kích thước file log hiệu quả.
• local_infile: Cho phép tải dữ liệu từ file, cần thiết khi di chuyển dữ liệu với các phương pháp import/export.
• server_id: Xác định ID của server MySQL trong quá trình replicate.
• log_bin / binlog_format: Bật chế độ ghi log binary và định dạng ROW giúp ghi nhận chi tiết các thay đổi trên từng bản ghi, phù hợp cho việc replicate dữ liệu với DMS.

Lý do: Những tùy chỉnh này giúp quá trình migrate diễn ra ổn định, đảm bảo hệ thống không bị quá tải và giảm thiểu khả năng mất kết nối khi truyền tải dữ liệu.

Bước 4: Cấu hình MySQL target (aws)

Tôi đã chỉnh sửa file cấu hình /etc/my.cnf trên MySQL đích để tối ưu quá trình migration. Dưới đây là các tùy chọn quan trọng mà tôi đã thêm:

net_read_timeout=6000
net_write_timeout=6000
wait_timeout=6000
expire_logs_days=7

2. Thiết lập AWS DMS

1. Tạo replication instance:

Đầu tiên, tôi đã tạo một replication instance trên AWS DMS. Đây là một thành phần quan trọng giúp quản lý quá trình replicate dữ liệu từ cơ sở dữ liệu nguồn sang đích. Việc chọn kích thước phù hợp cho instance (CPU, RAM) là rất quan trọng, vì nó ảnh hưởng trực tiếp đến tốc độ và hiệu suất của quá trình migrate, với dữ liệu của tôi, tôi đã chọn Class dms.r5.2xlarge và Engine version 3.5.3 với các bản lỗi đã được fixed, các bạn có thể tham khảo AWS DMS release notes  mỗi một version có một bản vá khác nhau, các bạn nên đọc qua để lựa chọn Engine version phù hợp.

2. Thiết lập endpoint:

• Source endpoint: Cấu hình này bao gồm thông tin kết nối với cơ sở dữ liệu MySQL trên cloud khác, sử dụng địa chỉ IP tĩnh và thông tin đăng nhập hợp lệ.
• Target endpoint: Endpoint đích là EC2 Instance MySQL hoặc RDS trên AWS, đảm bảo rằng mọi bản ghi sẽ được sao chép chính xác vào đây.

Sau khi các bạn thiết lập endpoint cho source và target các bạn nhớ test connection nhé!

3. Chọn loại migration task:

AWS DMS cung cấp các loại task khác nhau, và tôi đã chọn loại “Migrate existing data and replicate ongoing changes”. Điều này giúp tôi vừa chuyển toàn bộ dữ liệu hiện có, vừa giữ cho dữ liệu mới thêm vào sau khi bắt đầu migration vẫn được cập nhật liên tục.

Dưới đây là các bước:

4. Test Premigration Assessments - Đánh giá trước khi migrate

Sau khi thiết lập loại migration task trong AWS DMS, một bước quan trọng cần thực hiện trước khi bắt đầu quá trình migrate dữ liệu chính thức là Premigration assessments. Đây là một quy trình đánh giá hệ thống trước khi di chuyển dữ liệu để đảm bảo rằng không có lỗi hoặc vấn đề tiềm ẩn nào có thể ảnh hưởng đến quá trình di chuyển.

Tại sao cần thực hiện Premigration assessments?

• Kiểm tra tính tương thích: Premigration assessments giúp đảm bảo rằng cấu trúc cơ sở dữ liệu nguồn tương thích với cơ sở dữ liệu đích trên AWS. Điều này đặc biệt quan trọng nếu cơ sở dữ liệu nguồn sử dụng các tính năng mà DMS không hỗ trợ đầy đủ.
• Phát hiện lỗi trước: Bạn có thể phát hiện các lỗi tiềm ẩn, như kiểu dữ liệu không tương thích, thiếu khóa chính (primary key), hoặc những vấn đề về bảng không được hỗ trợ (ví dụ: các bảng có phân vùng).
• Xác nhận dữ liệu đầy đủ: Premigration assessments giúp bạn kiểm tra rằng tất cả các bảng và dữ liệu cần thiết đều được bao gồm trong quá trình migrate, đảm bảo không có dữ liệu nào bị bỏ sót.

Các bạn hãy vào trong Database migration tasks -> Premigration Assessments -> Create Premigration Assessments

Dưới đây là IAM role (dms-vpc-role) của DMS của tôi

Các bạn nhớ chọn đủ 22 assessments.

Sau khi tạo thành công thì các bạn sẽ thấy kết quả failed and warnings and passed

Nếu trong source DB có sử dụng pattioning giống mình mà bị lỗi như trên thì k cần phải quá lo lắng, nó failed thế thôi nhưng nó vẫn hoạt động, các bạn có thể click vào mô tả để hiểu hơn về mỗi description.

5. Run task

Ok vậy là gần xong rồi, các bạn click vào Actions -> Restart/Resume nó sẽ tự động chạy task cho các bạn.

Lưu ý: Trong một trường hợp nào đó bạn đã stopped task của bạn và bạn muốn bật trở lại thì nhớ chọn Resume nhé!

Kết quả chúng ta sẽ nhìn thấy dữ liệu đang được insert, update, delete và tổng số bản ghi đã được migrate.

Kết luận

Quá trình migrate hơn 200 triệu bản ghi từ cloud khác lên AWS đã diễn ra thành công nhờ sự chuẩn bị kỹ lưỡng về cấu hình nguồn, sử dụng các tính năng mạnh mẽ của AWS DMS như CDC và quản lý tốt tài nguyên. Đây là một hành trình đầy thách thức nhưng đồng thời cũng là cơ hội học hỏi nhiều kinh nghiệm quý giá trong việc xử lý lượng dữ liệu lớn trên các nền tảng đám mây.