Bối cảnh: Khi nào nên chia tay MySQL tự quản lý?
Tự build MySQL trên VPS nghe thì tiết kiệm, nhưng khi database chạm mốc 50GB+, mọi thứ bắt đầu “khó thở”. Mình từng thức trắng đêm vì một cụm MySQL trên EC2 bị nghẽn Disk I/O tới 98%. Lúc đó, ứng dụng web gần như tê liệt, còn mình thì loay hoay với các script replication thủ công. Việc tự quản lý không chỉ tốn thời gian mà còn tiềm ẩn rủi ro mất dữ liệu cực cao nếu phần cứng gặp sự cố.
Các dịch vụ Managed Database như Amazon RDS hay Google Cloud SQL giải quyết triệt để vấn đề này. Khi chuyển dịch lên Cloud, bạn sẽ sở hữu:
- Vận hành rảnh tay: Tự động backup và vá lỗi hệ điều hành (OS patching) định kỳ.
- Sẵn sàng cao (HA): Thiết lập Multi-AZ giúp hệ thống tự phục hồi trong chưa đầy 60 giây nếu một zone gặp sự cố.
- Mở rộng linh hoạt: Nâng cấp từ 2 vCPU lên 16 vCPU chỉ trong vài phút, thay vì phải cài đặt lại toàn bộ server.
Tuy nhiên, di chuyển hàng trăm GB dữ liệu mà không làm gián đoạn dịch vụ là một bài toán khó. Dưới đây là những kinh nghiệm xương máu mình rút ra sau nhiều dự án migrate thực tế.
Chuẩn bị môi trường: Đừng bỏ qua bước kiểm tra mạng
Sai lầm phổ biến nhất là chạy lệnh migrate trực tiếp từ máy cá nhân qua Wifi. Chỉ cần mạng chập chờn 1 giây, quá trình dump dữ liệu suốt 3 tiếng của bạn sẽ hỏng sạch. Hãy luôn dùng một Jump Server (EC2 hoặc Compute Engine) nằm cùng vùng (Region) với database đích để điều phối.
1. Cài đặt công cụ cần thiết
Đảm bảo phiên bản mysqldump trên server trung gian tương đương hoặc mới hơn bản database hiện tại. Trên Ubuntu, bạn thực hiện cài đặt nhanh:
sudo apt update && sudo apt install mysql-client -y2. Thông tuyến kết nối (Networking)
Lỗi “Connection Timeout” chiếm đến 80% các ca migrate thất bại trong lần đầu thử nghiệm.
- AWS RDS: Thêm Inbound Rule vào Security Group, cho phép port 3306 từ IP của server nguồn.
- Google Cloud SQL: Đưa IP server nguồn vào “Authorized Networks”. Nếu muốn bảo mật hơn, hãy dùng Cloud SQL Auth Proxy để tạo tunnel mã hóa.
3. Tối ưu cấu hình để tăng tốc
Trước khi bắt đầu, hãy tăng giá trị max_allowed_packet lên 128MB hoặc 256MB trên cả hai đầu. Điều này giúp xử lý các dòng dữ liệu lớn (Longtext, Blob) mượt mà hơn. Ngoài ra, hãy dùng flag --single-transaction để dump dữ liệu mà không làm khóa (lock) các table đang hoạt động.
Quy trình Migrate chi tiết cho từng nền tảng
Cách 1: Migrate lên Amazon RDS bằng phương pháp Pipe
Với các database dung lượng nhỏ (dưới 20GB), bạn có thể đẩy trực tiếp dữ liệu từ nguồn sang đích mà không cần tạo file trung gian. Cách này giúp tiết kiệm không gian đĩa cho Jump Server.
mysqldump -u [user_nguon] -p[pass_nguon] --databases [db_name] \
--single-transaction --compress --order-by-primary --set-gtid-purged=OFF \
| mysql -u [user_rds] -p[pass_rds] -h [endpoint_rds] [db_name]Lưu ý: Flag --set-gtid-purged=OFF cực kỳ quan trọng khi migrate lên RDS để tránh lỗi quyền Superuser.
Cách 2: Migrate lên Google Cloud SQL qua Cloud Storage
Với database lớn (trên 100GB), việc đẩy trực tiếp qua internet rất rủi ro. Hãy chia nhỏ quy trình thông qua Google Cloud Storage (GCS) để đảm bảo tính ổn định.
- Export dữ liệu:
mysqldump -u root -p --databases my_db --single-transaction --routines --triggers > backup.sql - Upload lên GCS:
Dùnggsutilđể tận dụng đường truyền nội bộ của Google:gsutil cp backup.sql gs://your-bucket-name/ - Import vào Cloud SQL:
Vào Console, chọn Import và trỏ đến file trong bucket. Đừng quên cấp quyềnStorage Object Viewercho Service Account của Cloud SQL trước khi chạy lệnh này.
Kiểm tra sau migrate: Những lỗi “ngớ ngẩn” đắt giá
Đừng vội trỏ Domain về server mới ngay khi lệnh import báo thành công. Hãy dành ít nhất 30 phút để thực hiện các bước sau:
1. Đối soát dữ liệu (Data Integrity)
Đừng chỉ đếm tổng số dòng. Hãy kiểm tra giá trị AUTO_INCREMENT hiện tại của các table quan trọng để đảm bảo không có bản ghi nào bị nhảy vọt hoặc mất mát.
2. Bài học về múi giờ (Timezone)
Đây là lỗi mình từng gặp khiến toàn bộ báo cáo doanh thu bị lệch 7 tiếng. RDS thường mặc định dùng UTC. Nếu ứng dụng của bạn mặc định dùng UTC+7, hãy nhớ cập nhật lại time_zone trong Parameter Group của Cloud provider.
3. Theo dõi hiệu năng thực tế
Hãy bật Performance Insights (AWS) hoặc Query Insights (GCP). Sau khi migrate, cấu hình mặc định của Cloud có thể khác với server cũ. Hãy kiểm tra thông số innodb_buffer_pool_size, nếu nó quá thấp, ứng dụng của bạn sẽ chạy chậm hơn đáng kể dù CPU vẫn rảnh.
Migrate database thành công không chỉ nằm ở việc gõ đúng lệnh. Nó nằm ở sự chuẩn bị kỹ lưỡng và khả năng kiểm soát các chi tiết nhỏ nhất. Chúc các bạn có một đợt “chuyển nhà” dữ liệu êm đẹp!
