Bối cảnhRedis master trên môi trường production của bạn vừa đột ngột chuyển sang chế độ chỉ đọc (read-only). Mọi yêu cầu từ ứng dụng nhằm cập nhật key đều gặp lỗi này: NOREPLICAS Not enough good replicas to write.
Hãy coi đây là một khóa an toàn. Lỗi này xảy ra khi bạn đã cấu hình Redis để đảm bảo tính nhất quán cao bằng chỉ thị min-replicas-to-write. Redis từ chối chấp nhận dữ liệu vì không thể đảm bảo rằng bản cập nhật sẽ được đồng bộ sang đủ số lượng replica khỏe mạnh. Nó thà ngừng hoạt động còn hơn là mạo hiểm mất dữ liệu khi có sự cố chuyển đổi dự phòng (failover).
Quy trình gỡ lỗiBắt đầu bằng cách kiểm tra tình trạng sao chép trực tiếp trên master node của bạn. Chạy lệnh này trong terminal:
redis-cli -h <master-ip> -p 6379
> INFO replication
Quan sát kỹ kết quả đầu ra. Bạn có thể thấy nội dung tương tự như sau:
# Replication
role:master
connected_slaves:1
slave0:ip=10.0.1.5,port=6379,state=online,offset=12345,lag=15
min_slaves_good_slaves:0
Bằng chứng rõ ràng ở đây là min_slaves_good_slaves:0. Mặc dù một replica hiển thị là "online", nhưng lag (độ trễ) của nó đã tăng vọt lên 15 giây. Redis chỉ tính một replica là "tốt" (good) nếu độ trễ heartbeat của nó thấp hơn ngưỡng min-replicas-max-lag mà bạn đã thiết lập.
Bây giờ, hãy kiểm tra các giới hạn hiện tại của bạn:
> CONFIG GET min-replicas-to-write
1) "min-replicas-to-write"
2) "2"
> CONFIG GET min-replicas-max-lag
1) "min-replicas-max-lag"
2) "10"
Trong ví dụ này, Redis đang chờ 2 replica khỏe mạnh với độ trễ dưới 10 giây. Vì chúng ta chỉ có một replica và nó đang bị chậm 15 giây, master đã tự khóa lại để bảo vệ tính toàn vẹn của dữ liệu.
Các giải pháp### 1. Bản sửa lỗi khẩn cấp để khôi phục dịch vụNếu ứng dụng của bạn bị ngừng hoạt động và bạn cần khôi phục dịch vụ ngay lập tức, bạn có thể tạm thời vô hiệu hóa việc kiểm tra sức khỏe này. Đây là một sự đánh đổi: trang web của bạn hoạt động trở lại, nhưng bạn có nguy cơ mất dữ liệu nếu master bị sập trước khi kịp đồng bộ sang replica.
> CONFIG SET min-replicas-to-write 0
Lệnh này có hiệu lực ngay lập tức mà không cần khởi động lại. Hãy sử dụng nó như một giải pháp tạm thời trong khi bạn tìm hiểu nguyên nhân gốc rễ của hạ tầng.
2. Khắc phục tình trạng sức khỏe của ReplicaĐể giải quyết vấn đề này một cách triệt để, bạn cần tìm hiểu lý do tại sao các replica gặp khó khăn. Truy cập SSH vào các replica node và kiểm tra log:
tail -n 100 /var/log/redis/redis-server.log
Tôi thường tìm kiếm bốn nguyên nhân chính sau:
- Tắc nghẽn mạng: Độ trễ cao giữa các vùng khả dụng của AWS hoặc các trung tâm dữ liệu có thể khiến các gói tin heartbeat (replconf acks) đến muộn.- Áp lực bộ nhớ: Nếu replica chạm ngưỡng 95% mức sử dụng RAM và phải sử dụng swap trên ổ đĩa, nó sẽ không phản hồi master kịp lúc.- CPU tăng vọt: Các lệnh
KEYS *nặng hoặc các script Lua chuyên sâu có thể làm nghẽn vòng lặp sự kiện của Redis.- Các tác vụ lưu trữ dữ liệu lớn: Quá trình tạo snapshot RDB lớn hoặc ghi lại AOF (AOF rewrite) có thể khiến replica không phản hồi trong vài giây.### 3. Điều chỉnh theo thực tế mạngNếu các node của bạn nằm rải rác ở các vùng cloud khác nhau (ví dụ: us-east-1 đến us-west-2), giới hạn độ trễ 10 giây có thể quá khắt khe. Bạn có thể làm cho fileredis.conflinh hoạt hơn với các sự cố mạng nhỏ:
# Trong redis.conf
min-replicas-to-write 1
min-replicas-max-lag 20
Đừng quên: CONFIG SET chỉ thay đổi instance đang chạy. Luôn cập nhật file cấu hình vật lý để các thiết lập vẫn tồn tại sau khi khởi động lại.
Xác minhSau khi sửa các replica hoặc nới lỏng các thiết lập, hãy chạy lại INFO replication. Bạn cần thấy min_slaves_good_slaves đạt hoặc vượt mức yêu cầu. Kiểm tra bằng một lệnh ghi đơn giản:
> SET health_check "ok"
OK
Nếu bạn thấy OK, lệnh chặn ghi đã chính thức được gỡ bỏ.