Hướng dẫn tối ưu hóa ProxySQL trên VPS Ubuntu để giải quyết nghẽn cổ chai Database MySQL (2026)

Hệ thống vừa chạy chiến dịch marketing, traffic đổ về ầm ầm. Ứng dụng phình to và bạn bắt đầu nhận được những tin nhắn cảnh báo đỏ rực trên Slack: CPU của máy chủ Database đang chạm nóc 100%. Các lỗi Too many connections hoặc 502/504 Gateway Timeout xuất hiện dày đặc, dẫn đến bài toán quá tải Database, web quay đều dù các Web Server (App Node) của bạn vẫn đang nhàn rỗi với 10% CPU.

Theo phản xạ, bạn hối hả nâng cấp RAM và đắp thêm lõi CPU cho Database, hay cố gắng tăng biến max_connections. Nhưng chỉ vài ngày sau, tình trạng quá tải lại tái diễn. Tiền server thì tăng gấp đôi, nhưng hiệu năng thực tế lại giậm chân tại chỗ. Việc ném tiền vào phần cứng rõ ràng không phải là cách giải quyết triệt để.

Trong kiến trúc hệ thống hiện đại, mở rộng App Server (stateless) rất dễ vì chỉ cần thêm node sau Load Balancer, nhưng mở rộng Database MySQL (stateful) lại là một bài toán vô cùng phức tạp. Đó là lúc bạn cần một lớp khiên trung gian thông minh. Trong bài hướng dẫn tối ưu hóa ProxySQL trên VPS này, chúng ta sẽ đi sâu vào cách thiết lập ProxySQL, một Layer 7 SQL-aware proxy, giúp bạn phân tách luồng Đọc/Ghi tự động, gom nhóm hàng ngàn kết nối rác và cứu rỗi CPU của MySQL.

Bạn đã sẵn sàng để hệ thống hiện tại chịu tải gấp đôi, thậm chí gấp ba chỉ với vài dòng cấu hình hạ tầng chuẩn chỉ chưa? Hãy bắt tay vào việc.

Nút thắt cổ chai mang tên MySQL & cơ chế hoạt động của ProxySQL

Trước khi gõ lệnh cài đặt, là một kỹ sư hệ thống, chúng ta phải xác định đúng nguyên nhân cốt lõi của MySQL. Tại sao nó lại dễ dàng sụp đổ dưới áp lực truy cập đồng thời?

Thảm họa Thread-per-Connection và Context Switching

Mặc định, MySQL thiết kế theo mô hình Thread-per-Connection, mỗi kết nối từ máy khách (client) sẽ được cấp phát một luồng hệ điều hành (OS thread) riêng biệt. Khi kiến trúc của bạn chuyển sang Microservices, số lượng máy khách bùng nổ, kéo theo hàng ngàn kết nối speculative (mở sẵn chờ tải) đâm thẳng vào MySQL.

Lúc này, CPU không quá tải vì thực thi query, mà cạn kiệt tài nguyên vì Context Switching (chuyển ngữ cảnh). Hệ điều hành phải liên tục hoán đổi CPU qua lại giữa hàng ngàn luồng để phục vụ yêu cầu. Hàng đợi dài dằng dặc, CPU kiệt sức, và database chính thức treo.

ProxySQL giải cứu CPU bằng Connection Multiplexing (ghép kênh)

Không giống như HAProxy (chỉ hoạt động ở Layer 4, chuyển tiếp TCP thô), ProxySQL hoạt động ở Layer 7, hiểu sâu sắc giao thức MySQL.

• Bản chất: 95% thời gian của một kết nối từ ứng dụng đến database là thời gian rỗi (idle).
• Giải pháp: ProxySQL tách rời hoàn toàn kết nối Frontend (từ ứng dụng) và Backend (tới MySQL). Khi MySQL trả xong kết quả cho một truy vấn, ProxySQL ngay lập tức ngắt kết nối backend đó và trả về Pool chung để phục vụ request của client khác.
• Thành quả: Nhờ tỷ lệ ghép kênh ấn tượng (có thể lên tới 100:1), hệ thống của bạn có thể hứng 10,000 kết nối từ ứng dụng nhưng thực chất chỉ mở khoảng 100 đến 200 kết nối thực tế tại MySQL. CPU hoàn toàn được giải phóng khỏi việc quản lý luồng rác.

Hướng dẫn tối ưu hóa ProxySQL trên VPS Ubuntu (thực chiến 100%)

Lưu ý: Bài viết giả định bạn đã có một cụm MySQL Master-Replica đang hoạt động. Các bước dưới đây sẽ được triển khai trên VPS chạy Ubuntu 24.04 LTS (Noble Numbat) hoặc 26.04 LTS (Resolute Raccoon).

Bước 1: Cài đặt chuẩn bảo mật trên Ubuntu (bỏ qua apt-key)

Từ Ubuntu 22.04 trở đi, lệnh apt-key đã bị khai tử. Nhiều bài hướng dẫn cũ sẽ khiến bạn gặp lỗi ngay bước này. Chúng ta bắt buộc phải sử dụng cơ chế signed-by với keyring riêng biệt.

Cập nhật danh sách gói phần mềm:

sudo apt-get update

Cài đặt các công cụ nền tảng cần thiết:

sudo apt-get install -y wget ca-certificates gnupg lsb-release

Tạo thư mục chứa keyring:

sudo mkdir -p /etc/apt/keyrings

Tải và giải mã khóa GPG trực tiếp vào keyring của ProxySQL (phiên bản 3.0.x):

wget -qO- https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/repo_pub_key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/proxysql-keyring.gpg

Khai báo kho lưu trữ ProxySQL:

echo "deb [signed-by=/etc/apt/keyrings/proxysql-keyring.gpg] https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/$(lsb_release -is | tr '[:upper:]' '[:lower:]')/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/proxysql.list

Cập nhật lại danh sách gói và cài đặt ProxySQL:

sudo apt-get update
sudo apt-get install -y proxysql

Kích hoạt khởi động cùng hệ thống và chạy dịch vụ ProxySQL:

sudo systemctl enable proxysql
sudo systemctl start proxysql

Bước 2: Đổi mật khẩu Admin và cấu hình Monitor User (tương thích MySQL 8.0)

ProxySQL có giao diện Admin lắng nghe ở cổng 6032. Mặc định tài khoản là admin:admin, bạn phải đổi ngay lập tức để đảm bảo tiêu chuẩn bảo mật.

Đăng nhập vào Admin (chỉ cho phép truy cập từ localhost):

mysql -u admin -padmin -h 127.0.0.1 -P 6032 --prompt='ProxySQLAdmin> '

Đổi mật khẩu tài khoản quản trị:

UPDATE global_variables SET variable_value='admin:MatKhauAdminSieuBaoMat' WHERE variable_name='admin-admin_credentials';
LOAD ADMIN VARIABLES TO RUNTIME;
SAVE ADMIN VARIABLES TO DISK;

Tạo tài khoản Monitor trên MySQL Backend:

ProxySQL cần một tài khoản để ping và kiểm tra độ trễ đồng bộ (Replication lag). Tuy nhiên, vì Ubuntu 24.04/26.04 cài mặc định MySQL 8.0+ (sử dụng plugin caching_sha2_password), kết nối giám sát của ProxySQL rất dễ bị từ chối nếu cấu hình SSL chưa chuẩn.

Để khắc phục, hãy tạo user monitor với plugin mysql_native_password. Trên máy chủ MySQL Master, chạy lệnh sau:

CREATE USER 'monitor'@'%' IDENTIFIED WITH mysql_native_password BY 'Monitor_Pass_2026';
GRANT SELECT ON sys.* TO 'monitor'@'%';
GRANT REPLICATION CLIENT ON *.* TO 'monitor'@'%'; -- Quyền bắt buộc để track độ trễ và GTID
FLUSH PRIVILEGES;

Quay lại giao diện ProxySQL Admin, khai báo tài khoản này:

UPDATE global_variables SET variable_value='monitor' WHERE variable_name='mysql-monitor_username';
UPDATE global_variables SET variable_value='Monitor_Pass_2026' WHERE variable_name='mysql-monitor_password';
UPDATE global_variables SET variable_value='2000' WHERE variable_name='mysql-monitor_ping_interval';

LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

Bước 3: Định nghĩa Hostgroup và cấu hình tự động Failover

Để tránh việc phải chuyển server thủ công khi có node mất kết nối, chúng ta sẽ để ProxySQL tự động theo dõi cờ read_only của MySQL thông qua bảng mysql_replication_hostgroups.

Quy ước hệ thống: Hostgroup 10 (Master/Writer) và Hostgroup 20 (Replica/Reader).

-- Khai báo cặp đồng bộ tự động
INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup, comment) 
VALUES (10, 20, 'Cluster DB Chinh');

-- Khai báo Master Backend
INSERT INTO mysql_servers (hostgroup_id, hostname, port, max_replication_lag) 
VALUES (10, '192.168.1.51', 3306, 5);

-- Khai báo 2 Node Replica Backend
INSERT INTO mysql_servers (hostgroup_id, hostname, port, max_replication_lag) 
VALUES (20, '192.168.1.52', 3306, 5);
INSERT INTO mysql_servers (hostgroup_id, hostname, port, max_replication_lag) 
VALUES (20, '192.168.1.53', 3306, 5);

LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;

Bước 4: Thiết lập Query Rules và chống Stale Read bằng GTID (tuyệt đối quan trọng)

Phần lớn các hướng dẫn trên mạng sẽ khuyên bạn dùng Regex thô sơ như ^SELECT để đẩy mọi truy vấn đọc sang Replica. Nếu làm vậy, bạn sẽ dính ngay lỗi Stale Read (đọc dữ liệu cũ). User vừa đổi mật khẩu, đăng nhập lại hệ thống vẫn báo sai vì Replica chưa kịp đồng bộ từ Master.

Tài liệu chính thức của ProxySQL đã gắn cờ đỏ cảnh báo việc dùng routing rules chung chung. Thay vào đó, ProxySQL 3.x hỗ trợ GTID Causal Reads (Read-Your-Writes). Nó biết chính xác transaction của bạn đã được replay ở Replica hay chưa. Nếu chưa, nó tự động giữ truy vấn đọc đó ở lại Master.

Cấu hình thực chiến:

-- 1. Khai báo User ứng dụng, mặc định đẩy mọi query chưa phân loại về Master để an toàn tuyệt đối
INSERT INTO mysql_users (username, password, default_hostgroup, transaction_persistent, gtid_causal_reads) 
VALUES ('app_user', 'App_Pass_Mat', 10, 1);

LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;

(Cờ transaction_persistent = 1 khóa chặt toàn bộ truy vấn trong khối BEGIN...COMMIT ở lại Master).

Tạo rules thông minh:

DELETE FROM mysql_query_rules;

-- LUẬT 1 (Ưu tiên ID 10): Đảm bảo các truy vấn khóa dòng (FOR UPDATE) luôn đi về Master.
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) 
VALUES (10, 1, '(?i)\sFOR\s+(UPDATE|SHARE)', 10, 1);

-- LUẬT 2 (Ưu tiên ID 20): Bắt lệnh SELECT thông thường sang Replica (HG 20). 
-- (Cơ chế track GTID ngầm của ProxySQL sẽ bảo vệ rule này khỏi việc đọc dữ liệu cũ).
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) 
VALUES (20, 1, '^(\/\*.*\*\/)?[[::space:]]*(?i)SELECT', 20, 1);

LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

Bây giờ, bạn đã có một kiến trúc phân tách Read/Write an toàn 100%.

Tuyệt chiêu Tuning ProxySQL cho môi trường Production

Trải nghiệm Web Dashboard built-in của ProxySQL 3.0.x

Trước đây, để xây dựng hệ thống giám sát proxy bằng Grafana và Prometheus, sysadmin phải thiết lập rất cồng kềnh. Ở phiên bản 3.0.x, Sysown đã tích hợp sẵn một Historical Monitoring Dashboard chạy trực tiếp trên cổng REST API. Không tốn thêm một byte RAM nào cho ứng dụng bên thứ 3!

Vào Admin và kích hoạt:

UPDATE global_variables SET variable_value='true' WHERE variable_name='admin-restapi_enabled';
UPDATE global_variables SET variable_value='6070' WHERE variable_name='admin-restapi_port';
UPDATE global_variables SET variable_value='true' WHERE variable_name='admin-web_dashboard_enabled';

LOAD ADMIN VARIABLES TO RUNTIME;
SAVE ADMIN VARIABLES TO DISK;

Bạn chỉ cần mở trình duyệt, gõ http://<IP_CUA_VPS>:6070/ để theo dõi các biểu đồ thời gian thực về Connection Pool, Query hits, và Throughput cực kỳ trực quan.

Kích hoạt Query Caching tại tầng Proxy

Thay vì bắt MySQL phải xử lý các truy vấn SELECT lặp đi lặp lại (như load cấu hình hệ thống, menu), bạn có thể bắt chúng ngay tại ProxySQL.

-- Lưu cache bảng 'categories' trên RAM của ProxySQL trong 30 giây (30000ms)
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, cache_ttl, apply) 
VALUES (30, 1, '(?i)^SELECT \* FROM categories', 20, 30000, 1);

LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

3 lỗi kinh điển cần tránh khi vận hành ProxySQL

Rất nhiều hệ thống đã gặp sự cố giữa chừng vì những sai lầm kiến trúc sau:

1. Biến ProxySQL thành SPOF (Single Point of Failure): Dựng một lớp khiên cực mạnh nhưng lại chỉ có 1 node duy nhất. Node đó mất kết nối, toàn bộ ứng dụng không thể truy cập Database. Hãy chạy cụm 2 node ProxySQL dùng Keepalived (Virtual IP), hoặc cài theo mô hình Sidecar (ProxySQL nằm ngay trên App Node). Nhớ bật tính năng ProxySQL Cluster (P2P) để chúng tự đồng bộ rules cấu hình cho nhau.
2. Khinh suất với Regex Routing: Sử dụng nguyên rule ^SELECT áp dụng cho mọi thứ mà không cấu hình transaction_persistent=1 hoặc GTID. Hậu quả là các query kiểm tra tồn kho lúc thanh toán bị đẩy sang Replica, dẫn đến bán lố hàng tỷ đồng do Replica bị lag 2 giây.
3. Lỗi quên lưu cấu hình (SAVE TO DISK): Chỉnh sửa rule xong xuôi, gõ LOAD ... TO RUNTIME thấy hoạt động ổn định là kết thúc phiên làm việc. Tháng sau bảo trì restart lại VPS, ProxySQL reset về cấu hình trống trơn vì bạn chưa gõ SAVE ... TO DISK;.

Câu hỏi thường gặp (FAQ)

1. ProxySQL khác gì HAProxy khi cân bằng tải Database?

HAProxy (Layer 4) chỉ chuyển tiếp gói tin TCP thô. ProxySQL (Layer 7) có khả năng đọc hiểu cú pháp SQL để tự động phân tách Đọc/Ghi (Read/Write Split) và ghép kênh kết nối (Multiplexing) giúp giải phóng CPU cho Database.

2. Cài ProxySQL trên cùng VPS với App (mô hình Sidecar) hay VPS riêng?

Cả hai đều tốt, nhưng KHÔNG cài chung với Database.

• VPS riêng (Centralized): Phù hợp cụm lớn, dễ quản lý tập trung (cần cấu hình 2 node + Keepalived để tránh SPOF).
• Cùng App (Sidecar): Khuyên dùng cho Microservices. App gọi DB qua localhost độ trễ cực thấp và tự nhiên triệt tiêu được điểm lỗi duy nhất (SPOF).

3. Làm sao để giám sát ProxySQL?

Từ bản 3.0.x, bạn không cần cài thêm công cụ nặng nề. Chỉ cần vào giao diện Admin bật REST API, sau đó truy cập http://<IP_VPS>:6070/ để xem trực tiếp Web Dashboard thời gian thực do chính ProxySQL tích hợp sẵn. Nếu hệ thống dùng Grafana, chỉ cần trỏ Prometheus thu thập metrics thẳng từ port 6070.

4. Cấu hình transaction_persistent = 1 có bắt buộc không?

Bắt buộc 100%. Nếu tắt, các lệnh SELECT nằm ngay sau lệnh UPDATE trong cùng một giao dịch sẽ bị đẩy sang Replica. Do Replica có độ trễ đồng bộ (lag), ứng dụng sẽ bị lỗi đọc dữ liệu cũ (Stale Read).

5. Lỗi “Access denied” khi ProxySQL Monitor kết nối MySQL 8.0?

Do Ubuntu 24.04 và MySQL 8.0+ đổi sang chuẩn mã hóa mới (caching_sha2_password).

Cách sửa: Vào Master xóa user monitor cũ, tạo lại bằng lệnh CREATE USER 'monitor'@'%' IDENTIFIED WITH mysql_native_password BY 'password';.

Kết luận

Mở rộng phần cứng (Scale-up) thiếu quy hoạch chỉ là giải pháp tạm thời. Khi bạn áp dụng hướng dẫn tối ưu hóa ProxySQL trên VPS này, bạn đã trang bị cho hệ thống một trung tâm điều phối ở Layer 7. Bạn giải quyết triệt để nút thắt Context Switching ở CPU MySQL nhờ Multiplexing, và tạo ra một luồng Read/Write Split an toàn tuyệt đối nhờ công nghệ GTID.

Tất cả những điều này được thực hiện một cách trong suốt, không đòi hỏi developer phải thức đêm đập đi viết lại bất kỳ dòng code Backend nào.

Tài liệu tham khảo

• ProxySQL Design Goals, ProxySQL Documentation
• How to Set Up ProxySQL Read/Write Split, ProxySQL Documentation
• Connection Multiplexing | ProxySQL Features
• Releases · sysown/proxysql