TL;DR
Redis Sentinel không tìm được replica để thăng cấp trong quá trình failover. Ba nguyên nhân phổ biến nhất: tất cả replica có slave-priority 0, replica bị tụt hậu quá xa về replication offset, hoặc replica không thực sự kết nối. Chạy SENTINEL replicas <master-name> để xem chính xác bạn đang gặp điều kiện nào.
Nguyên Nhân Gây Ra Lỗi Này
Khi master bị sập, Sentinel chấm điểm các replica đã biết để chọn ứng viên thăng cấp. Điểm quá thấp ở bất kỳ kiểm tra điều kiện nào? Replica đó bị bỏ qua.
Nếu mọi replica đều thất bại, bạn sẽ nhận được:
NOGOODSLAVE No suitable slave to promote
Sentinel ghi lỗi này vào /var/log/redis/sentinel.log và hủy bỏ. Cluster của bạn tiếp tục ngừng hoạt động cho đến khi bạn can thiệp thủ công.
Một replica bị loại nếu bất kỳ điều kiện nào sau đây đúng:
- slave-priority bằng 0 — bị loại trừ rõ ràng khỏi việc thăng cấp
- Độ trễ replication quá cao — offset tụt hậu quá xa so với vị trí cuối cùng đã biết của master
- Replica bị ngắt kết nối — Sentinel không thể liên lạc hoặc replica hiển thị trạng thái
disconnectedtrong thông tin của nó - Replica bị sập — bị crash hoặc không thể truy cập từ bất kỳ node Sentinel nào
Bước 1: Xem Sentinel Đang Nghĩ Gì
Bắt đầu từ đây trước khi làm bất cứ điều gì khác. Kết nối tới bất kỳ Sentinel đang chạy nào và lấy danh sách replica:
redis-cli -p 26379 SENTINEL replicas mymaster
Với mỗi replica, đây là các trường quan trọng cần chú ý:
flags: slave
role-reported: slave
slave-priority: 100
replica-announced: 1
last-ok-ping-reply: 312
slave-repl-offset: 1048576
master-link-status: ok
Những dấu hiệu cho thấy có vấn đề:
slave-priority: 0→ bị loại khỏi việc thăng cấp (xem Fix 1)master-link-status: err→ replica không đồng bộ với master (xem Fix 3)flags: disconnectedhoặcflags: s_down→ Sentinel coi replica này đã chếtlast-ok-ping-replylên tới hàng nghìn ms → có vấn đề mạng giữa Sentinel và replica
Fix 1: slave-priority Được Đặt Thành 0
Priority 0 là tín hiệu có chủ đích: "đừng bao giờ thăng cấp replica này." Thường gặp trên các node chỉ dùng cho backup hoặc analytics — các replica bạn không muốn nhận lưu lượng truy cập trực tiếp. Vấn đề xảy ra khi mọi replica đều được đặt như vậy. Không còn ai để thăng cấp.
Kiểm tra priority hiện tại của từng replica:
redis-cli -h 192.168.1.11 -p 6380 CONFIG GET slave-priority
Nếu trả về 0, hãy nâng lên giá trị mặc định:
redis-cli -h 192.168.1.11 -p 6380 CONFIG SET slave-priority 100
Thay đổi đó có hiệu lực ngay lập tức nhưng sẽ không tồn tại sau khi khởi động lại. Để lưu vĩnh viễn, thêm dòng này vào /etc/redis/redis.conf trên replica đó:
slave-priority 100
Trên Redis 5.0+, cả hai tên đều dùng được:
replica-priority 100
Fix 2: Replica Bị Tụt Hậu
Có một ngưỡng min-slaves-max-lag trong Sentinel (cũng được viết là min-replicas-max-lag trong các cấu hình mới hơn). Bất kỳ replica nào có độ trễ replication vượt quá số giây này sẽ bị loại. Giá trị mặc định là 10 giây.
Kiểm tra ngưỡng hiện tại trực tiếp trên master:
redis-cli CONFIG GET min-replicas-max-lag
Sau đó kiểm tra độ trễ thực tế trên replica:
redis-cli -h 192.168.1.11 -p 6380 INFO replication
So sánh master_last_io_seconds_ago với ngưỡng. Nếu độ trễ liên tục cao — chẳng hạn 30–60 giây — bạn có hai lựa chọn:
Phương án A: Tăng tạm thời ngưỡng độ trễ trên Sentinel trong khi bạn tìm nguyên nhân gốc rễ:
redis-cli -p 26379 SENTINEL set mymaster min-slaves-max-lag 60
Phương án B: Khắc phục nguyên nhân khiến replica bị tụt hậu. Các thủ phạm thường gặp là mạng bị bão hòa giữa master và replica, I/O ổ đĩa chậm trên HDD dưới tải ghi nặng, hoặc instance replica không đủ tài nguyên. Tìm ra điểm nghẽn cổ chai và để replica bắt kịp trước sự kiện failover tiếp theo.
Fix 3: Replica Bị Ngắt Kết Nối
master-link-status: err có nghĩa là replica đã mất liên lạc với master trước hoặc trong quá trình xảy ra sự cố. Nếu master đã chết, bạn không thể kết nối lại replica với nó — hãy trỏ nó tới một node lành mạnh trước.
Buộc replica đồng bộ từ một host cụ thể:
redis-cli -h 192.168.1.11 -p 6380 REPLICAOF 192.168.1.10 6379
Đang trong quá trình failover mà Sentinel vẫn không chọn được người thắng? Kích hoạt thủ công:
redis-cli -p 26379 SENTINEL failover mymaster
Vẫn thất bại? Tự thăng cấp replica:
# Biến nó thành master độc lập
redis-cli -h 192.168.1.11 -p 6380 REPLICAOF NO ONE
# Xác nhận đã thực hiện
redis-cli -h 192.168.1.11 -p 6380 INFO replication
Sau đó trỏ các replica còn lại tới master mới:
redis-cli -h 192.168.1.12 -p 6380 REPLICAOF 192.168.1.11 6380
Fix 4: Trạng Thái Sentinel Bị Cũ
Sentinel theo dõi replica nội bộ và không phải lúc nào cũng dọn dẹp sau khi ngừng sử dụng. Xóa một replica mà không thông báo cho Sentinel, và entry ma đó sẽ còn đó — gây ảnh hưởng tới các quyết định failover. Buộc reset:
redis-cli -p 26379 SENTINEL RESET mymaster
Chạy lệnh này trên mọi node Sentinel. Nó xóa trạng thái nội bộ và học lại topology hiện tại từ đầu. Chờ vài giây, sau đó xác minh danh sách đã sạch:
redis-cli -p 26379 SENTINEL replicas mymaster
Xác Minh Sau Khi Sửa
Sau khi áp dụng một fix, hãy kiểm tra nó. Đừng chờ đến sự cố thực tế tiếp theo để phát hiện ra nó không hoạt động.
Kích hoạt failover thủ công:
redis-cli -p 26379 SENTINEL failover mymaster
Theo dõi log của Sentinel trực tiếp trong terminal thứ hai:
tail -f /var/log/redis/sentinel.log
Một failover thành công sẽ tạo ra các dòng này theo thứ tự:
+selected-slave slave 192.168.1.11:6380 @ mymaster 192.168.1.10 6379
+failover-state-send-slaveof-noone slave 192.168.1.11:6380 @ mymaster
+promoted-slave slave 192.168.1.11:6380 @ mymaster
Xác nhận master mới thực sự đang phản hồi:
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# Trả về: ["192.168.1.11", "6380"]
redis-cli -h 192.168.1.11 -p 6380 PING
# Trả về: PONG
Phòng Ngừa Trong Môi Trường Production
Duy trì ít nhất hai replica đủ điều kiện — nghĩa là slave-priority trên 0 — trong mọi cluster do Sentinel quản lý. Một replica đủ điều kiện là điểm lỗi đơn cho toàn bộ đường failover của bạn.
Sử dụng replica chỉ để backup với priority 0 là ổn. Chỉ cần đảm bảo ít nhất một replica khác có thể tiếp quản nếu mọi thứ trở nên tồi tệ.
Thêm cảnh báo kích hoạt khi số lượng replica đủ điều kiện về 0:
redis-cli -p 26379 SENTINEL replicas mymaster | grep -c 'slave-priority'
Cũng kiểm tra lại sentinel.conf của bạn — đây là những giá trị thường khiến các team bị bất ngờ nhất:
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel min-replicas-to-write 1
sentinel min-replicas-max-lag 10
Quorum bằng 2 có nghĩa là hai Sentinel phải đồng ý rằng master đã sập trước khi failover được khởi động. 5 giây down-after-milliseconds và 60 giây failover-timeout là điểm khởi đầu hợp lý — hãy tinh chỉnh dựa trên độ trễ mạng của bạn và mức downtime bạn có thể chấp nhận.