Posted inMySQL

Backup & Restore MySQL tốc độ cao: Rút ngắn thời gian từ 15 giờ xuống 2 giờ với Mydumper

MySQL tutorial - IT technology blog
MySQL tutorial - IT technology blog

Khi mysqldump trở thành gánh nặng cho hệ thống

Hồi mới vào nghề, mình luôn dùng mysqldump vì nó là công cụ mặc định, cực kỳ dễ dùng. Mọi chuyện vẫn êm đềm cho đến khi dự án mình quản lý cán mốc 200GB dữ liệu. Lúc này, các table log đã vượt ngưỡng 50 triệu bản ghi, biến việc backup hàng đêm thành một thử thách thực sự.

Vấn đề lớn nhất của mysqldump là nó chạy đơn luồng (single-thread). Nó chỉ tận dụng duy nhất một CPU core để xử lý lượng dữ liệu khổng lồ. Kết quả là mình mất hơn 6 tiếng để backup xong. Thậm chí, khi restore thử để kiểm tra, thời gian chờ đợi lên tới gần 15 tiếng. Trong môi trường production, nếu server gặp sự cố mà mất nửa ngày để khôi phục thì uy tín của đội kỹ thuật chắc chắn “bay màu”.

Sau khi chuyển sang mydumper và myloader, thời gian backup giảm xuống còn 40 phút. Quá trình restore cũng chỉ mất chưa đầy 2 tiếng. Dưới đây là những kinh nghiệm thực chiến giúp bạn làm chủ bộ đôi này.

Tại sao mydumper lại vượt trội hơn?

Sự khác biệt nằm ở cách tiếp cận dữ liệu. Nếu mysqldump giống như việc bạn chuyển nhà bằng một chiếc xe tải nhỏ chạy đi chạy lại, thì mydumper là cả một đội xe tải xuất phát cùng lúc.

  • Sức mạnh đa luồng (Multi-threading): Bạn có thể huy động 8, 16 hoặc 32 thread để đọc dữ liệu song song.
  • Cơ chế chia nhỏ file (Chunking): Thay vì xuất ra một file SQL nặng hàng trăm GB, mydumper chia nhỏ dữ liệu theo từng table. Với các table lớn, nó tự động cắt thành nhiều phần (chunks). Nhờ đó, myloader có thể nạp nhiều file vào database cùng lúc, tận dụng tối đa tài nguyên server.
  • Nén dữ liệu tức thời: Quá trình nén diễn ra ngay khi dump, giúp tiết kiệm dung lượng lưu trữ mà không gây nghẽn cổ chai CPU.
  • Đảm bảo tính nhất quán: Công cụ này sử dụng FLUSH TABLES WITH READ LOCK trong tích tắc để lấy tọa độ binlog, sau đó dùng transaction cho các table InnoDB để đảm bảo dữ liệu luôn khớp nhau (snapshot).

Cài đặt nhanh trên Linux

Mydumper không đi kèm sẵn trong gói cài đặt MySQL. Tuy nhiên, việc cài đặt trên các distro phổ biến như Ubuntu hay CentOS rất nhanh chóng:

# Dành cho Ubuntu/Debian
sudo apt update
sudo apt install mydumper -y

# Dành cho CentOS/RHEL
sudo yum install epel-release -y
sudo yum install mydumper -y

Nếu hệ thống của bạn yêu cầu các tính năng mới nhất, hãy ưu tiên tải bản build sẵn từ trang GitHub chính thức của dự án.

Cách Backup hiệu quả với mydumper

Giả sử bạn cần backup database prod_db. Thay vì các câu lệnh đơn giản, hãy sử dụng các tham số tối ưu sau:

mydumper \
  --host=127.0.0.1 \
  --user=admin_user \
  --password='your_password' \
  --database=prod_db \
  --threads=8 \
  --rows=500000 \
  --compress \
  --build-empty-files \
  --outputdir=/data/backups/$(date +%F) \
  --verbose=3

Giải mã các tham số quan trọng:

  • --threads=8: Tận dụng 8 nhân CPU. Kinh nghiệm của mình là đặt số thread bằng khoảng 70% tổng số core của server.
  • --rows=500000: Đây là “vũ khí” quan trọng nhất. Nếu table orders có 10 triệu dòng, nó sẽ chia thành 20 file nhỏ thay vì 1 file khổng lồ. Điều này giúp việc restore sau này nhanh hơn gấp nhiều lần.
  • --compress: Nén file output bằng gzip, giảm đáng kể gánh nặng cho ổ cứng.

Khôi phục thần tốc với myloader

Khi cần cứu dữ liệu, myloader sẽ tự động đọc metadata trong thư mục backup để thực hiện quy trình khôi phục tối ưu nhất.

myloader \
  --host=127.0.0.1 \
  --user=admin_user \
  --password='your_password' \
  --directory=/data/backups/2023-10-27 \
  --queries-per-transaction=50000 \
  --threads=8 \
  --database=prod_db_restored \
  --overwrite-tables \
  --verbose=3

Mẹo nhỏ: Trước khi chạy lệnh này, hãy tạm thời tăng innodb_buffer_pool_size lên mức cao nhất có thể để MySQL có thêm không gian xử lý.

4 lưu ý sống còn khi vận hành thực tế

Sau 6 tháng áp dụng cho các hệ thống lớn, mình rút ra 4 bài học giúp bạn tránh các sự cố đáng tiếc:

1. Kiểm soát Disk IOPS

Do chạy đa luồng, mydumper ngốn tài nguyên đọc/ghi rất mạnh. Nếu chạy backup trực tiếp trên ổ cứng đang chứa database, ứng dụng có thể bị lag, treo (slow query tăng vọt). Tốt nhất, hãy backup ra một ổ đĩa riêng hoặc thực hiện trên một con Slave (Read Replica).

2. Đừng quên tham số –rows

Nhiều bạn quên --rows dẫn đến việc một table nặng 100GB chỉ được xử lý bởi đúng 1 thread. Lúc này, dù bạn set 64 thread thì tốc độ vẫn sẽ chậm như rùa vì gặp hiện tượng nghẽn cổ chai ở table lớn nhất.

3. Dung lượng thư mục tạm

Hãy đảm bảo phân vùng chứa dữ liệu backup có dung lượng trống ít nhất bằng 1.5 lần dung lượng database thực tế. Việc thiếu bộ nhớ giữa chừng khi đang dump sẽ khiến toàn bộ bản backup bị hỏng.

4. Tối ưu cấu hình MySQL khi restore

Để đạt tốc độ nạp dữ liệu kịch trần, hãy tạm thời tắt các cơ chế kiểm tra ràng buộc bằng lệnh:

SET GLOBAL autocommit = 0;
SET GLOBAL unique_checks = 0;
SET GLOBAL foreign_key_checks = 0;

Đừng quên bật lại các thông số này sau khi quá trình restore hoàn tất để đảm bảo an toàn dữ liệu.

Tóm lại, nếu database của bạn đã vượt ngưỡng 20GB, hãy mạnh dạn gạt mysqldump sang một bên. Chuyển sang mydumper không chỉ giúp tiết kiệm thời gian, mà còn là phương án bảo hiểm an toàn nhất cho hệ thống khi đối mặt với rủi ro mất dữ liệu.

Share:
Tags: