Tình huốngBạn đang khắc phục sự cố thiết lập Redis High Availability (HA) và mọi thứ có vẻ ổn định bên ngoài. Tuy nhiên, ngay khi bạn truy vấn một node Sentinel để lấy địa chỉ của master, hệ thống lại từ chối. Thay vì trả về một IP, giao diện dòng lệnh (CLI) hiển thị một lỗi khá thẳng thừng:
127.0.0.1:26379> SENTINEL get-master-addr-by-name production-cluster
(error) IDONTKNOW No such master with that name
Sentinel đang báo cáo chính xác thực tế. Lỗi này xảy ra khi tên master trong lệnh của bạn không khớp với tên mà tiến trình Sentinel hiện đang lưu giữ trong bộ nhớ hoạt động.
Tìm điểm sai lệchPhản hồi IDONTKNOW có nghĩa là chuỗi ký tự của bạn không tồn tại trong hệ thống. Dưới đây là cách truy tìm nơi cấu hình bị sai lệch.
1. Kiểm tra các master đang được giám sátBắt đầu bằng cách hỏi Sentinel xem nó thực sự đang theo dõi cái gì. Lệnh SENTINEL masters là nguồn thông tin chính xác nhất. Nó liệt kê mọi nhóm master hiện đang được theo dõi bởi node cụ thể đó.
127.0.0.1:26379> SENTINEL masters
Kiểm tra trường name trong kết quả đầu ra. Thông thường, master vẫn được đặt tên là mymaster (mặc định của Redis) trong khi ứng dụng của bạn lại mong đợi production-cluster. Thậm chí một lỗi đánh máy nhỏ—như prod_cluster so với prod-cluster—cũng sẽ làm hỏng kết nối.
2. Kiểm tra tệp sentinel.confNếu lệnh masters trả về một danh sách trống, cấu hình đã không được tải đúng cách. Mở tệp cấu hình của bạn (thường tại /etc/redis/sentinel.conf) và tìm dòng monitor:
# Định dạng: sentinel monitor <master-name> <ip> <port> <quorum>
sentinel monitor redis-main 10.0.0.15 6379 2
Nếu dòng này bị thiếu hoặc có dấu # ở phía trước, Sentinel sẽ bỏ qua hoàn toàn master đó. Điều này dẫn đến lỗi IDONTKNOW mỗi khi truy vấn.
3. Phân biệt chữ hoa chữ thườngTên trong Redis Sentinel có phân biệt chữ hoa chữ thường. Truy vấn PROD_DB khi cấu hình định nghĩa là prod_db sẽ thất bại. Ngoài ra, hãy cẩn thận với các khoảng trắng thừa ở cuối nếu bạn chỉnh sửa cấu hình thủ công. Một số phiên bản Redis cũ có thể coi khoảng trắng ở cuối tên là một phần của chính chuỗi đó.
Cách khắc phục lỗiSau khi xác định được điểm không khớp, hãy sử dụng một trong ba cách sau để giải quyết.
Tùy chọn A: Cập nhật truy vấnNếu SENTINEL masters cho thấy master được đặt tên là mymaster, cách sửa nhanh nhất là cập nhật các biến môi trường của ứng dụng. Hãy khớp mã nguồn của bạn với cấu hình hiện có.
# Lệnh này thất bại
SENTINEL get-master-addr-by-name redis-prod
# Lệnh này hoạt động (khớp với cấu hình thực tế)
SENTINEL get-master-addr-by-name mymaster
Tùy chọn B: Đăng ký Master một cách linh hoạtBạn không cần khởi động lại dịch vụ để sửa lỗi thiếu master. Bạn có thể yêu cầu Sentinel bắt đầu giám sát một nhóm master mới trực tiếp bằng CLI. Điều này hữu ích để thêm các node mà không gây gián đoạn hoạt động.
127.0.0.1:26379> SENTINEL MONITOR production-db 10.0.0.20 6379 2
Sentinel thường tự động ghi lại tệp cấu hình của chính nó khi bạn chạy lệnh này. Tuy nhiên, thói quen tốt là kiểm tra thủ công sentinel.conf sau đó để đảm bảo thay đổi vẫn còn sau khi khởi động lại.
Tùy chọn C: Sửa tệp cấu hìnhNếu tên trong tệp cấu hình bị sai hoàn toàn, hãy sửa nó và khởi động lại dịch vụ. Đây là cách sạch nhất để đảm bảo tất cả các node trong một cluster luôn đồng bộ.
# Chỉnh sửa cấu hình
sudo nano /etc/redis/sentinel.conf
# Cập nhật dòng:
sentinel monitor production-db 10.0.0.20 6379 2
# Khởi động lại dịch vụ
sudo systemctl restart redis-sentinel
Xác minhXác nhận việc khắc phục bằng cách yêu cầu chi tiết cho tên master cụ thể. Bạn sẽ thấy một danh sách key-value chi tiết thay vì một thông báo lỗi.
127.0.0.1:26379> SENTINEL master production-db
Nếu trường flags hiển thị master, node đó đang hoạt động tốt. Cuối cùng, hãy chạy lệnh phân giải địa chỉ để đảm bảo ứng dụng của bạn có thể tìm thấy IP:
127.0.0.1:26379> SENTINEL get-master-addr-by-name production-db
1) "10.0.0.20"
2) "6379"