AWS Database Migration Service là một cách tuyệt vời để thực hiện migrate data với những tính năng nâng cao. Trong bài viết này, tôi sẽ mô tả cách để có thể setup cross-account database migration từ RDS MySQL sang Aurora Serverless MySQL, từ một account AWS sang một account AWS khác và lý do sử dụng AWS Database Migration Service (DMS).
Thách thức
Gần đây mình nhận một nhiệm vụ là phải migrate data từ MySQL server sang một Aurora Serverless MySQL đang nằm ở một account AWS khác, trong bài viết này mình chỉ nói về migrate data, cách tạo RDS Serverless MySQL thì sẽ nằm ở một bài chia sẻ khác.
Cả hai MySQL (source) và Aurora Serverless MySQL (target) đều được đặt trong một private sunet trong một VPC nhằm mục đích bảo mật cho nên chũng ta không thể access cả hai từ public internet.
Việc migrate data chỉ sử dụng trong một hoặc hai lần, cho nên mình không cần phải giữ cho target DB luôn được đồng bộ với source DB.
Việc xử lý các loại dữ liệu nâng cao hơn đi kèm với những thách thức bổ sung và không được xem xét cho bài đăng này.
Giải pháp
Mục tiêu của cách này là mình không muốn thực hiện việc export data, mapping data và import data một cách thủ công, điều này có thể dẫn đến việc sai xót data trong quá trình migrate. Việc chọn DMZ cũng một phần vì nó dễ thực hiện.
Như một giải pháp, tôi đã dựa vào AWS Database Migration Service (DMS) cho phép xác định các data migration tasks — với sự hỗ trợ cho schema, table và column filtering & mapping giữa source và target DB. Đối với khía cạnh cross-account — inter-region — data migration Tôi đã sử dụng một VPC Peering connection, kết nối này cho phéo tôi tạo một private network connection giữa private subnets ở cả source và target VPC's.
Các bước thực hiện như sau:
- Tạo một VPC Peering connection từ target VPC đến source VPC
- Tạo một private DMS Replication Instance (EC2) bên trong Target VPC
- Tạo một DMS Replication Source Endpoint cho RDS MySQL
- Tạo một DMS Replication Target Endpoint cho RDS Aurora Serverless MySQL
- Tạo một DMS Replication Task
- Thực hiện việc migrate
Điều kiện tiên quyết
Trước khi bắt đầu cần chắc chắn những điều đã được noted bên dưới:
- Account IDs của cả 2 AWS accounts.
- VPC IDs của cả hai AWS accounts
- CIDR ranges của cả hai target và source VPCs
- MySQL database endpoint, server name, port, user name, password
- Aurora Serverless MySQL database endpoint, server name, port, user name, password
Tạo VPC Peering Connection
VPC Peering connection kết nối VPC trong target account với VPC trong source account qua đó có thể thực hiện private communication trở nên có thể thông qua IPv4. Điều quan trọng nhất của việc tạo VPC Peering connection là CIDR blocks giữa hai VPCs không được chồng chéo nhau.
Tạo VPC Peering connection khá dễ dàng:
- Login và AWS Console trong Target Account của bạn và chọn “AWS Services > VPC”
- Trong menu bên trái chọn “Peering Connections”
- Click vào nút “Create Peering Connection” để tạo một peering connection mới và điền những thông tin chi tiết vào và chọn “Create Peering Connection”

Nhập chi tiết về local and destination VPC:
- VPC (Requester): là ID của VPC trong local Aurora account.
- Account: chọn “Another account”và nhậu vào Account ID MySQL account (source account).
- Region: chọn “Another Region”và chọn region của MySQL Account
- VPC ID (Accepter): nhập VPC ID của MySQL
Khi khi tạo, accepter sẽ nhận được một VPC peering request dưới Account account của họ và cần phải accept VPC peering request:
- Login và AWS Console trong Serouce Account của bạn và chọn “AWS Services > VPC”
- Trong menu bên trái chọn “Peering Connections”
- Chọn peering connection với pending status và chọn Actions > Accept Request
Đảm bảo bật DNS Resolution trên cả hai phía của peering connection để chúng tôi có thể nhắm mục tiêu source và target DB theo IPv4 nhưng thay vào đó là DNS names:
- Chọn peering connection and then Actions > Edit DNS Settings
- Phía Requester: check “Allow accepter VPC (vpc-XXX) to resolve DNS of requester VPC (vpc-YYY) hosts to private IP”
- Phía Accepter: check “Allow requester VPC (vpc-YYY) to resolve DNS of accepter VPC (vpc-XXX) hosts to private IP”
- Cuối cùng,
Cuối cùng, chỉnh sửa Route tables đã liên kết với những subnets chứa source và target database của bạn. Bước này có thể hoàn thành ngay sau khi tạo Peering Connection:
- Mở Route Tables
- Chọn route tables đã liên kết với database và chọn Actions > Edit Routes
- Nhấn “Add route” và điền VPC's CIDR range đích dưới Destination và Target chọn “Peering Connection” và chọn connection mà chúng ta đã tạo.

VPC Peering connection giữa source và target VPC đã được thiết lập. Giờ chúng ta sẽ setup AWS DMS service.
Cài đặt AWS DMS Replication Instance
DMS Replication Instance là một Amazon EC2 instance được đặt trong một VPC của target (MySQL Aurora Serverless) database và nó được dùng để thực hiện Replication Tasks để migrate data từ source endpoint sang target endpoint. Để access tới source database nó sẽ sử dụng VPC Peering connection mới được tạo.
Các bước để tạo Replication Instance:
- Mở AWS DMS trong AWS Console
- Chọn Create replication instance
- Đặt cho instance một cái tên có ý nghĩa và điền phần mô tả.
- Trong dự án này tôi chọn default là
dms.t3.medium
Instance class là đã đủ capacity để thực hiện việc migrate của tôi. - Version thì tôi cứ để phiên bản mới nhất.
- Chắc chắn rằng bạn chọn đúng VPC của target (MySQL Aurora Serverless) database.
- Vì lý do bảo mật và an toàn nên tôi đã tắt Publicly accessible checkbox. Chúng ta không cần access vào instance để làm gì và nó sử dụng private VPC peering connection để kết nối tới database cho nên chúng ta không cần phải public EC2 instance.
Tôi để những trường khác mặc định. Giờ chọn “Create” và instance sẽ được tạo.
Việc khởi tạo Instance có thể mất tới 15 phút
Khi đã được khởi tạo, private instance sẽ có một địa chỉ IPv4. Ghi lại địa chỉ IP này và tiến hành chỉnh sửa Security Groups của MySQL Aurora Serverless (Target) và MySQL Community (Source) để có thể truy cập được từ Replication Instance tới các databases:
- Mở Security Group đã associated với database
- Chọn Actions > Edit inbound rules
- Chọn Type trong dropdown là “MYSQL/Aurora”
- Nhập vào địa chỉ private IPv4 ở phần source Source, EX:
/32
(e.g.10.0.10.100/32
). - Nhập Description (Mô tả) cho inbound rule
Lưu ý rằng Source mà bạn nhập vào tên Security Group ID của Replication Instance (e.g. “SG-XXX”) chứ không phải là địa chỉ IPv4.
Replication Instance bây giờ đã có thể truy cập được vào hai databases.
Tạo DMS Database Endpoints
Trong bước này, mình sẽ tạo cả hai Source (MySQL) và Target (Aurora MySQL) DMS Endpoints để Migration Task có thể sử dụng được.
Tạo Source Endpoint theo các bước bên dưới:
- Mở Endpoints list và chọn Create endpoint
- Chọn Source endpoint
- Điền vào Endpoint identifier
- Ở Source engine chọn “MySQL”
- Nhập vào các thông tin xác thực của database ngay bên dưới Access to endpoint database > provide access information manually
- Tôi để Endpoint-specific settings mặc định
- Test endpoint connection (optional)
Tạo Target Endpoint:
- Mở Endpoints list và chọn Create endpoint
- Chọn Target endpoint
- Chọn “Amazon Aurora MySQL Serverless” ở phần Target Engine
- Nhập thông tin chi tiết của connection
- Khi Aurora MySQL của bạn sử dụng một key nào đó ngoài KMS master key để mã hóa dữ liệu thì phải chắc chắn rằng bạn chọn đúng key ở phần KMS key

Bây giờ cả hai DMS Endpoints đã được khởi tạo, chúng ta đã đi đến final step; Khởi tạo DMS Database migration task.
Tạo DMS Database Migration Task
Giờ sẽ khởi tạo Database Migration Task để chúng ta có thể thực hiện migration. Ở Database migration tasks trong menu và chọn Create Task.
Nhập những thông tin bên dưới vào trong Task Configuration:
- Chọn Replication Instance mà chúng ta mới tạo
- Chọn Source database endpoint mà chúng ta mới tạo
- Select the Target database endpoint we've just created
- Chọn “Migrate existing data” ở phần Migration Type nếu như bạn muốn copy data một lần hoặc 2 lần thôi, và không muốn sync những data thay đổi mới ở source db.
Sử dụng Task Settings Wizard để cấu hình task. Dĩ nhiên JSON mapping cũng là một sự lựa chọn hay nhưng trong ví dụ này tôi sửa dụng Wizard vì nó khá dễ dùng và có thể thực hiện hầu hết các cấu hình mà tôi cần
- Ở Target table preparation mode mình chọn “Drop tables on trarget” để chắc chắn là không bị sai xót data trong khi migrate.
- Chọn “Enable CloudWatch logs” ta có thể check được thông tin log của replication instance log task trong CloudWatch.
Bên dưới Table mappings bạn có thể chọn một source scheme, whitelist/blacklist tables để apply schema, table và column dựa trên những thông tin cần chuyển đổi như đặt lại tên của MySQL schema sang một schema khác ở MySQL aurora serverless (e.g. “public”).
Bước đầu tiên là apply Selection rules. Nhập tên Source name là source database Schema. Mình đã sử dụng điều này để chỉ chọn một tập hợp con các bảng để migrate đến Target.
Sau đó cấu hình Transformation rules để apply schema, table and/or column level transformations. Mình sử dụng nó để migrate những tables từ source schema tới MySQL Aurora Server “public” schema của mình, rename tables và add “_aurora_prod” suffix để tránh lỗi trùng tên và dễ nhận biết hơn cũng như exclude một vài columns— chẳng hạn columns chứa những thông tin nhạy cảm.

Ở phần Migration task startup configuration mình chọn “Manually later” và nhấn Created task.
Bây giờ task đã được tạo và nó sẽ xuất hiện ở Database migration task dashboard.
Thực thi Migration Task
Để thực thi migration task, chọn nó từ danh sách tasks và chọn Actions > Start. Migration task sẽ bắt đầu.
Chọn migration tasks' và chọn Quick view and compare button để get xem chi tiết các thông tin trong Migration Task's:
- Overview Details
- Status and progress
- Table statistics: mapping, state, rows to be migrated, etc.
- CloudWatch metrics
- Mapping Rules (sẽ hữu ích nếu như ta copy lại JSON và sử dụng cho lần tạo instance mới lần sau)
Khi đã thành không thì nó sẽ báo là “Load complete” và progress là “100%”

Restarting
Nếu như bạn muốn thực thi lại migration, chỉ đơn giản là chọn task và chọn Action > Restart/Resume sau đó chọn Restart. Điều này sẽ hoàn thành bằng việc drop target table và thực hiện lại quá trình migration.

Khi thực thi thành công, data sẽ xuất hiện ở trong MySQL Aurora Server của bạn.
Kết luận
AWS Database Migration Service là một service dễ sử dụng và hữu ích cho database migrations.
Cuối cùng, tôi mất khoảng một giờ để hoàn thành thiết lập và thực hiện di chuyển cơ sở dữ liệu với hàng triệu hàng trong vòng chưa đầy 10 phút! Và tất cả đều được thực hiện với ít ảnh hưởng hiệu suất của trên Source cũng như Target databases nhất.
Mình tin rằng yêu cầu kết nối cả hai VPC bằng cách sử dụng mạng private VPC Peering và việc di chuyển giữa các tài khoản và giữa các region là một trường hợp sử dụng khá phổ biến. Việc mô tả cả thiết lập VPC Peering và AWS DMS trong một bài đăng sẽ giúp hiểu rõ hơn về thiết lập database migration end-to-end trong thực tế.
Một số bước di chuyển dữ liệu này có lẽ nâng cao hơn một chút dựa trên trải nghiệm của bạn với AWS, do đó, tôi hy vọng bài đăng này sẽ giúp ích được phần nào và loại bỏ bớt sự phức tạp đối với bất kỳ ai được yêu cầu di chuyển dữ liệu qua các tài khoản AWS.
Tips & Tricks
- Cross-region VPC peering không cho phép chúng ta áp dụng một tên security group từ source VPC (DMS instance) to the MySQL Aurora Serverless security group, cho nên chúng ta cần phải note lại địa chỉ DMS' private IP và thêm nó vào database's Security Group.
- Tạo một user chuyên dụng với quyền truy cập tối thiểu cho cơ sở dữ liệu nguồn và đích.
- Enable CloudWatch logging cho task để có thể thấy được detail logs
- Chúng ta có thể chỉnh sửa một migration task đã tồn tại and/or restart nó để có thể thực thi migration mà không cần tạo thêm cái mới.
Pricing
AWS DMS không thực sự đắt. Thông tin chi tiết giá cả ở đây AWS pricing table:
- Một on-demand Replication Instance với kiểu
dms.t3.medium
(single-AZ) là $0.146 mỗi giờ - CPU Credits đã thay đổi $ 0.075 mỗi vCPU-Hour
- Tất cả việc chuyển dữ liệu sang AWS Database Migration Service là miễn phí và dữ liệu được truyền giữa AWS Database Migration Service và database trong Phiên bản Amazon RDS và Amazon EC2 trong cùng Availability Zone cũng miễn phí. Tốc độ truyền dữ liệu AWS tiêu chuẩn áp dụng khi bạn di chuyển source database của mình sang target database trong Availability Zone, Region khác hoặc bên ngoài AWS