Redis Sentinel Trên VPS: Tự Động Failover Khi Primary Gặp Sự Cố

Một Redis primary có thể phục vụ cache, session hoặc hàng đợi cho nhiều ứng dụng. Nếu VPS đó dừng đột ngột, ứng dụng có thể mất kết nối ngay cả khi đã có Redis replica. Replica không đồng nghĩa với tự động failover: cần một cơ chế xác định lỗi, lựa chọn primary mới và thông báo địa chỉ mới cho client.

Redis Sentinel thực hiện những vai trò này cho Redis không chạy Cluster: monitoring, notification, automatic failover và cung cấp thông tin primary hiện tại cho client. Bài này tập trung vào tính sẵn sàng cao; nếu cần xử lý Redis thiếu RAM, xem bài Redis maxmemory, eviction và persistence trên VPS.

Kiến trúc mẫu: ba Redis, ba Sentinel

Mô hình tham khảo sử dụng ba VPS độc lập:

Các IP chỉ là ví dụ. Ba Sentinel cần chạy trên những failure domain độc lập ở mức phù hợp; chạy ba process Sentinel trên cùng VPS không giúp chịu được việc VPS đó hỏng. Redis khuyến nghị tối thiểu ba Sentinel cho triển khai vững chắc.

Redis mặc định dùng cổng 6379, Sentinel thường dùng 26379. Chỉ cho phép các node và application được ủy quyền truy cập qua private network; không mở hai cổng này công khai.

Replication trước, Sentinel sau

Cài Redis từ nguồn/package phù hợp với phiên bản hệ điều hành, rồi kiểm tra:

redis-server --version
redis-cli -h 127.0.0.1 PING

Trên hai replica, có thể khai báo trong cấu hình Redis:

replicaof 10.20.0.11 6379

Lưu ý: ví dụ này giả định kết nối replication đã được bảo vệ và thông suốt. Trong production, cấu hình bind, ACL/authentication, TLS và firewall phải hoàn chỉnh trước. Không vô hiệu hóa protected-mode chỉ để replica kết nối được.

Kiểm tra trên primary:

redis-cli INFO replication

Chú ý role:master, số replica và trạng thái kết nối. Trên replica cần thấy role:slave (tên field do Redis sử dụng) và link tới upstream ở trạng thái up.

Cấu hình Sentinel tối thiểu

Mỗi Sentinel cần một file cấu hình có quyền ghi để tự cập nhật topology trong quá trình failover. Ví dụ file cấu hình riêng cho redis-01:

port 26379
bind 10.20.0.11
sentinel monitor mymaster 10.20.0.11 6379 2
sentinel down-after-milliseconds mymaster 10000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

Trên hai máy còn lại, thay dòng bind bằng IP private đúng của từng máy; phần sentinel monitor ban đầu cùng tham chiếu primary redis-01. Những giá trị thời gian là khởi điểm để thử nghiệm, không phải SLA cam kết. Nếu Redis có ACL/mật khẩu, bổ sung thông tin xác thực Sentinel theo tài liệu phiên bản; không lưu bí mật trong repository công khai.

Khởi chạy thử bằng lệnh phù hợp đường dẫn thực tế:

redis-server /path/to/sentinel.conf --sentinel

Trong production, cấu hình service systemd riêng, user không đặc quyền và quyền ghi file cấu hình. Dùng systemctl status và journal để kiểm tra sau khi cài.

Quorum 2 không đồng nghĩa chỉ cần hai Sentinel

Dòng:

sentinel monitor mymaster 10.20.0.11 6379 2

quy định có hai Sentinel cùng đánh giá primary không khả dụng để đạt objective down. Việc bầu Sentinel thực hiện failover còn cần đa số Sentinel trao quyền. Với ba Sentinel, chỉ một Sentinel còn sống sẽ không thể tự hoàn tất failover an toàn. Đây là thiết kế tránh hai phía mạng đều tự nhận có primary hợp lệ.

Kiểm tra khả năng hội đủ quorum và majority:

redis-cli -h 10.20.0.11 -p 26379 SENTINEL CKQUORUM mymaster

Lặp kiểm tra trên các Sentinel còn lại. Nếu không đạt, xem network, ACL, port và trạng thái process trước khi cố diễn tập failover.

Application phải hiểu Sentinel

Không nên hard-code endpoint Redis primary cũ trong ứng dụng rồi cho rằng Sentinel sẽ tự sửa mọi kết nối. Driver/client cần hỗ trợ Sentinel discovery, truy vấn tên logical master mymaster, tự reconnect và retry có giới hạn.

Truy vấn primary hiện tại bằng:

redis-cli -h 10.20.0.12 -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster

Kết quả sẽ thay đổi nếu có failover. Với worker và API, cần kiểm thử việc reconnect, retry và các thao tác có thể chạy lặp lại; tránh retry vô hạn làm nhân đôi giao dịch hoặc tạo retry storm.

Diễn tập failover trong staging

Trước khi làm với production, hãy tạo một môi trường staging, xác nhận backup và ứng dụng chịu được việc gián đoạn ngắn. Ghi lại role trước khi test:

redis-cli -h 10.20.0.11 INFO replication
redis-cli -h 10.20.0.12 -p 26379 SENTINEL MASTER mymaster

Chỉ trên môi trường thử nghiệm đã kiểm soát, dừng Redis primary (không dừng toàn bộ VPS nếu còn service khác):

sudo systemctl stop redis-server

Tên unit có thể khác theo package. Sau đó quan sát log Sentinel, chạy SENTINEL GET-MASTER-ADDR-BY-NAME mymaster và INFO replication trên Redis mới. Xác nhận app reconnect đúng. Khi bật lại primary cũ, nó thường được tái cấu hình thành replica của primary mới; không tự ép nó làm primary cũ nếu chưa hiểu dữ liệu và topology.

Giới hạn quan trọng: failover không đảm bảo không mất dữ liệu

Redis replication mặc định là bất đồng bộ. Write đã được primary xác nhận nhưng chưa truyền sang replica được promote có thể bị mất khi failover. Sentinel tối ưu availability, không phải mô hình transaction đồng bộ tuyệt đối. Các lựa chọn như WAIT, tuning min-replicas-to-write và retention/durability có thể giảm một số rủi ro nhưng không thay thế bài toán nhất quán dữ liệu.

Nếu Redis chỉ lưu cache tái tạo được, mất vài key có thể chấp nhận. Nếu Redis giữ dữ liệu giao dịch không thể mất, bạn cần đánh giá lại RPO, sử dụng datastore phù hợp và kiểm thử recovery thực tế. Sentinel không phải backup: lỗi xóa key logic có thể lan tới replica.

Monitor điều gì?

Theo dõi tối thiểu:

• Trạng thái Redis primary/replica và replication link;
• SENTINEL CKQUORUM và số Sentinel hoạt động;
• Số lần failover và thời gian application reconnect;
• Replication lag, Redis memory, disk persistence;
• Lỗi client write/read sau failover.

Có thể gửi các chỉ số tới Prometheus và Grafana, kết hợp Alertmanager để thông báo khi mất quorum hoặc replica. Cảnh báo nên phân biệt 'mất replica' và 'mất primary' để tránh spam.

Sai lầm thường gặp

Ba Sentinel trên một VPS: chỉ tăng số process, không tạo ba điểm chịu lỗi độc lập.

Mở 26379 ra Internet: tăng bề mặt tấn công không cần thiết. Chỉ cho phép kết nối nội bộ đúng nguồn.

Client chỉ kết nối IP primary tĩnh: failover diễn ra nhưng application không biết đường chuyển.

Đánh đồng failover với zero data loss: replication bất đồng bộ có khoảng mất dữ liệu tiềm năng.

Không có diễn tập khôi phục: tới sự cố mới phát hiện firewall, DNS hoặc client library không tương thích.

FAQ

Redis Sentinel và Redis Cluster khác nhau ở đâu?

Sentinel quản lý failover cho mô hình Redis primary/replica không chia shard. Redis Cluster bổ sung phân vùng dữ liệu và cơ chế cluster riêng. Không nên hoán đổi cấu hình hai mô hình.

Có bắt buộc phải có ba VPS?

Để có ba Sentinel trên ba failure domain độc lập, ba VPS là mô hình dễ hiểu. Quy mô thật phụ thuộc yêu cầu fault tolerance và hạ tầng hiện có.

Sentinel có tự sửa code ứng dụng không?

Không. Client phải hỗ trợ Sentinel discovery và cơ chế reconnect phù hợp.

Có cần backup khi đã có replica?

Có. Replica có thể sao chép cả thao tác xóa nhầm hoặc dữ liệu hỏng; backup giúp khôi phục theo chính sách riêng.

Có nên tắt primary production để thử không?

Chỉ khi đã có kế hoạch bảo trì, backup, monitoring và chấp nhận gián đoạn. Diễn tập staging trước.

Kết luận

Redis Sentinel giúp tự động phát hiện và xử lý lỗi primary nhưng chỉ hữu ích khi network, quorum, client discovery và quy trình vận hành đều đúng. Hãy đo RPO/RTO và diễn tập failover thay vì chỉ nhìn trạng thái Sentinel đang chạy.

Nếu cần các VPS độc lập để tách Redis primary, replica và lớp giám sát, bạn có thể tham khảo dịch vụ đang cung cấp tại HUONG CLOUD rồi lựa chọn cấu hình theo workload thực tế.

Nguồn tham khảo

• Redis Docs — High availability with Redis Sentinel
• Redis Docs — Replication