Bài 101: Sentinel — Automatic Failover

• Giải thích được vấn đề mà Sentinel giải quyết so với replication thuần (bài 100).
• Mô tả kiến trúc: Sentinel instance, master, replica và mối quan hệ giữa chúng.
• Hiểu quorum, SDOWN, ODOWN và vai trò của từng khái niệm trong failure detection.
• Biết quy trình failover từng bước: ODOWN → leader election → promote → reconfigure replicas → notify clients.
• Nắm tiêu chí Sentinel dùng để chọn replica (priority, replication offset, run_id).
• Viết được Sentinel client bằng redis-py Python với auto-discovery master/replica.
• Hiểu split-brain, min-replicas-to-write, deployment topology multi-AZ.
• Nhận diện limitations của Sentinel và khi nào cần chuyển sang Redis Cluster.

Replication master-replica cho phép replica đọc và cung cấp bản sao data realtime. Nhưng khi master crash, không có gì xảy ra tự động cả. Replicas chỉ tiếp tục chạy ở chế độ read-only và cố gắng reconnect lại master đã mất.

Để khôi phục, operator phải:

1. Phát hiện master đã down (qua alert, monitoring, hoặc thủ công).
2. Chọn replica phù hợp nhất để promote (thường là replica lag thấp nhất).
3. Chạy REPLICAOF NO ONE trên replica đó để biến nó thành master mới.
4. Reconfig các replica còn lại trỏ vào master mới bằng REPLICAOF <new_master_ip> <port>.
5. Cập nhật connection string hoặc load balancer để client trỏ đúng master mới.

Quy trình này mất từ vài phút đến hàng chục phút tùy trình độ và mức độ automation của team. Trong thời gian đó, toàn bộ write operation bị chặn.

Sentinel thay thế toàn bộ quy trình thủ công trên bằng cơ chế automated, distributed và có fault tolerance.

Sentinel là một process riêng biệt với Redis server, chạy song song và không lưu data. Một deployment Sentinel điển hình có:

• 1 master Redis: nhận toàn bộ write.
• 1–N replica Redis: nhận replication stream từ master, phục vụ read.
• 3+ Sentinel instances: monitor master và replicas, phối hợp failover với nhau.

Mỗi Sentinel instance:

• Gửi PING định kỳ tới master và tất cả replicas.
• Subscribe vào channel __sentinel__:hello của master để phát hiện Sentinel instances khác.
• Trao đổi thông tin trạng thái với các Sentinel khác qua Pub/Sub và kết nối trực tiếp.
• Vote khi có đề xuất failover.

Các Sentinel instances không share state qua shared storage — chúng tự đồng bộ hoàn toàn qua giao tiếp trực tiếp giữa các node. Đây là lý do cần chạy ít nhất 3 instance: để có quorum ngay cả khi một instance chết.

# Topology điển hình
#
#  [Sentinel A]  [Sentinel B]  [Sentinel C]
#       |              |              |
#       +------+-------+------+-------+
#              |              |
#         [Master :6379]  [Replica :6380]
#                           [Replica :6381]

File cấu hình Sentinel tối thiểu:

# sentinel.conf
port 26379

# Monitor master tên "mymaster" tại 127.0.0.1:6379, quorum = 2
sentinel monitor mymaster 127.0.0.1 6379 2

# Coi master là SDOWN nếu không phản hồi trong 5000ms
sentinel down-after-milliseconds mymaster 5000

# Timeout cho toàn bộ quá trình failover (ms)
sentinel failover-timeout mymaster 30000

# Số replica sync đồng thời với master mới sau failover
sentinel parallel-syncs mymaster 1

# Optional: password nếu master yêu cầu auth
# sentinel auth-pass mymaster yourpassword

# Optional: announce IP/port cho môi trường NAT, container
# sentinel announce-ip 10.0.1.5
# sentinel announce-port 26379

Khởi động Sentinel:

redis-sentinel /path/to/sentinel.conf
# hoặc
redis-server /path/to/sentinel.conf --sentinel

Lưu ý quan trọng: Sentinel tự ghi lại vào sentinel.conf khi trạng thái thay đổi (ví dụ sau failover). File cấu hình phải writable với process Sentinel. Không hardcode address master trong file và hy vọng nó sẽ bất biến — sau failover, Sentinel tự cập nhật địa chỉ master mới.

Chạy 3 Sentinel riêng biệt — mỗi Sentinel một file sentinel.conf riêng với port khác nhau (hoặc trên 3 máy khác nhau). Tất cả đều trỏ cùng một master ban đầu; chúng tự discover nhau qua Pub/Sub.

Quorum là số Sentinel tối thiểu phải đồng ý rằng master đã down trước khi bắt đầu failover. Quorum được chỉ định ở dòng sentinel monitor.

Quorum chỉ kiểm soát bước "bắt đầu failover" (đạt ODOWN). Để bầu leader Sentinel thực hiện failover, cần thêm một bước khác: majority vote trong số Sentinel instances (xem bước 2 của failover). Majority = ít nhất ⌊N/2⌋ + 1 trong tổng N Sentinel.

Bảng ví dụ:

Hai Sentinel là cấu hình dễ bị split-brain nhất: nếu 1 Sentinel mất kết nối, cả 2 phần đều không đạt quorum, failover không xảy ra được. Với 3 Sentinel, mất 1 node vẫn còn 2 node đủ quorum.

Quorum thấp hơn majority dễ trigger false failover hơn. Quorum bằng N (tất cả Sentinel) thì không bao giờ failover được khi bất kỳ Sentinel nào down. Recommendation chuẩn: quorum = majority = ⌊N/2⌋ + 1, và N là số lẻ.

Sentinel dùng 2 trạng thái để tránh false positive khi phát hiện master down:

SDOWN — Subjectively Down

Một Sentinel đơn lẻ không nhận được phản hồi từ master trong khoảng thời gian down-after-milliseconds. Đây là nhận định chủ quan của một node — có thể do mạng giữa node đó và master bị gián đoạn, không nhất thiết là master thực sự chết.

# Kiểm tra state qua redis-cli
redis-cli -p 26379 SENTINEL masters
# Xem trường "flags" — giá trị "s_down" = SDOWN

ODOWN — Objectively Down

Ít nhất quorum Sentinel instances đều báo cáo master là SDOWN. Tại điểm này, Sentinel xem master thực sự đã down theo cộng đồng — đây là trạng thái kích hoạt failover.

# Xem trường "flags" — giá trị "o_down" = ODOWN

Cơ chế 2 lớp này giúp tránh trường hợp một Sentinel bị cô lập khỏi master (nhưng master vẫn phục vụ các client bình thường) lại tự ý kích hoạt failover không cần thiết.

SDOWN áp dụng cho cả replica và Sentinel instance khác, nhưng chỉ ODOWN của master mới kích hoạt failover. Sentinel không tự failover replica hay Sentinel khác.

Sau khi master đạt ODOWN:

1. Leader election (Raft-like): các Sentinel bầu chọn 1 Sentinel làm leader để thực hiện failover. Cần majority vote — quá trình này thường hoàn tất trong vài trăm millisecond.
2. Chọn replica để promote: leader áp dụng tiêu chí theo thứ tự ưu tiên (xem mục 8).
3. Gửi REPLICAOF NO ONE tới replica được chọn. Replica ngừng nhận replication stream và chuyển thành master mới.
4. Reconfigure các replica còn lại: gửi REPLICAOF <new_master_ip> <new_master_port> tới từng replica khác. Config parallel-syncs kiểm soát bao nhiêu replica sync đồng thời — giá trị 1 để tránh quá tải master mới ngay sau promote.
5. Update Sentinel state: tất cả Sentinel instances cập nhật config file và trạng thái nội bộ với địa chỉ master mới.
6. Publish event: Sentinel publish message +switch-master lên Pub/Sub channel để notify clients và monitoring systems.
7. Old master demote: khi (và nếu) master cũ quay lại online, Sentinel tự động config nó thành replica của master mới. Không thể tự lấy lại vị trí master.

Toàn bộ quy trình từ ODOWN đến master mới sẵn sàng nhận write thường mất 5–15 giây trong điều kiện network bình thường.

Sentinel leader áp dụng tiêu chí theo thứ tự sau (loại bỏ dần các replica không đủ điều kiện):

1. Loại replica đang down hoặc lag quá cao: các replica không phản hồi hoặc có replication offset quá cũ bị loại trước.
2. replica-priority thấp nhất: config trên từng Redis instance (mặc định 100). Giá trị thấp hơn được ưu tiên hơn. Giá trị 0 có nghĩa là replica đó không bao giờ được promote.
3. Replication offset cao nhất: replica đã nhận nhiều data nhất từ master — ít khả năng mất data nhất sau promote.
4. Run ID lexicographically nhỏ nhất: tiebreaker cuối cùng khi offset bằng nhau.

Để kiểm soát thứ tự ưu tiên trong production:

# redis.conf trên từng replica
# Replica ở datacenter chính — ưu tiên cao (số nhỏ)
replica-priority 10

# Replica ở datacenter backup — ưu tiên thấp hơn
replica-priority 50

# Replica chỉ dùng cho read, không bao giờ promote
replica-priority 0

Vấn đề cốt lõi với client: sau failover, địa chỉ master thay đổi. Client không thể hardcode địa chỉ master — cần cơ chế discovery.

Sentinel cung cấp command để client tự hỏi địa chỉ master hiện tại:

# Kết nối tới bất kỳ Sentinel instance nào
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# Trả về: ["127.0.0.1", "6379"]
# Sau failover: ["127.0.0.1", "6380"]  (master mới)

Flow client discovery chuẩn:

1. Client cấu hình danh sách địa chỉ của tất cả Sentinel instances (không phải master).
2. Khi cần kết nối, client gọi SENTINEL get-master-addr-by-name tới một trong các Sentinel.
3. Sentinel trả về IP/port của master hiện tại.
4. Client kết nối tới master đó.
5. Khi connection bị đứt (failover xảy ra), client quay lại bước 2 để rediscover.

Sentinel-aware clients (như redis-py, ioredis, Jedis, StackExchange.Redis) tự động thực hiện quy trình này. Client không hỗ trợ Sentinel phải tự implement hoặc dùng reverse proxy layer.

from redis.sentinel import Sentinel
import time

# Khai báo danh sách Sentinel instances
# Client không cần biết địa chỉ master — Sentinel sẽ cung cấp
sentinel = Sentinel(
    [
        ("sentinel1.example.com", 26379),
        ("sentinel2.example.com", 26379),
        ("sentinel3.example.com", 26379),
    ],
    socket_timeout=0.5,
    # Tùy chọn: password Sentinel nếu có
    # sentinel_kwargs={"password": "sentinelpass"},
    # Password cho Redis instances
    # password="redispass",
)

# Lấy connection tới master (write)
# sentinel.master_for tự gọi SENTINEL get-master-addr-by-name
master = sentinel.master_for(
    "mymaster",
    socket_timeout=0.5,
    # decode_responses=True nếu muốn nhận string thay vì bytes
    decode_responses=True,
)

# Lấy connection tới replica (read) — round-robin nếu nhiều replica
replica = sentinel.slave_for(
    "mymaster",
    socket_timeout=0.5,
    decode_responses=True,
)

# Ghi vào master
master.set("user:1001", '{"name":"Alice","score":100}', ex=3600)

# Đọc từ replica — eventual consistent
value = replica.get("user:1001")
print(value)  # {"name":"Alice","score":100}

# Khi failover xảy ra, lần gọi tiếp theo sẽ tự reconnect
# redis-py Sentinel tự retry và rediscover master mới
def safe_write(key: str, value: str, ttl: int = 3600) -> bool:
    """Ghi với retry khi failover đang xảy ra."""
    for attempt in range(3):
        try:
            master.set(key, value, ex=ttl)
            return True
        except Exception as exc:
            print(f"Attempt {attempt + 1} failed: {exc}")
            time.sleep(0.5)
    return False

redis-py (v4.x+) tự handle reconnect và rediscovery sau failover. Sentinel object được tạo một lần và dùng lâu dài — không tạo mới mỗi request.

Sentinel publish events lên các channel Pub/Sub để client và monitoring system có thể theo dõi. Subscribe bằng cách kết nối tới port Sentinel (26379):

redis-cli -p 26379 PSUBSCRIBE '*'

Các events quan trọng:

Format message +switch-master:

# +switch-master <master-name> <old-ip> <old-port> <new-ip> <new-port>
+switch-master mymaster 192.168.1.10 6379 192.168.1.11 6380

Subscribe events trong Python để gửi alert:

import redis

# Kết nối tới Sentinel port, không phải Redis port
sentinel_conn = redis.Redis(host="sentinel1.example.com", port=26379)
pubsub = sentinel_conn.pubsub()
pubsub.psubscribe("*")  # subscribe tất cả events

for message in pubsub.listen():
    if message["type"] == "pmessage":
        channel = message["channel"].decode()
        data = message["data"].decode()
        if channel == "+switch-master":
            # Gửi alert: failover xảy ra
            print(f"FAILOVER: {data}")
        elif channel in ("+odown", "+sdown"):
            print(f"DOWN EVENT [{channel}]: {data}")

Kết nối trực tiếp tới Sentinel port để dùng các lệnh quản trị:

# Liệt kê tất cả master đang được monitor
SENTINEL masters

# Thông tin chi tiết 1 master
SENTINEL master mymaster

# Liệt kê replicas của mymaster
SENTINEL slaves mymaster
# (hoặc "replicas" từ Redis 5.x)
SENTINEL replicas mymaster

# Liệt kê các Sentinel khác đang monitor mymaster
SENTINEL sentinels mymaster

# Lấy địa chỉ master hiện tại
SENTINEL get-master-addr-by-name mymaster

# Trigger failover thủ công (dùng khi test hoặc planned maintenance)
SENTINEL failover mymaster

# Reset toàn bộ state của Sentinel cho một pattern tên
# Dùng khi cần re-discover topology sau thay đổi lớn
SENTINEL reset mymaster

# Xem thông tin Sentinel
SENTINEL info

SENTINEL failover mymaster là công cụ quan trọng để test định kỳ. Nó trigger failover có kiểm soát mà không cần thực sự kill master — nên chạy thường xuyên trong staging và production maintenance window để verify toàn bộ stack hoạt động đúng.

Với cấu hình down-after-milliseconds mymaster 5000 và failover-timeout mymaster 30000:

Nếu giảm down-after-milliseconds xuống 1000ms thì detect nhanh hơn nhưng tăng nguy cơ false positive với mạng có jitter. Giá trị 5000–10000ms là phổ biến trong production.

failover-timeout là tổng timeout cho toàn bộ quá trình failover. Nếu vượt quá, Sentinel sẽ retry từ đầu với leader mới. Giá trị 60000ms (60s) thường đủ an toàn.

Split-brain xảy ra khi network partition chia cluster thành nhiều phần, mỗi phần nghĩ rằng mình là "phần sống sót" và cố gắng hoạt động độc lập. Với Sentinel:

Kịch bản: Network partition giữa các Sentinel

Giả sử 3 Sentinel A, B, C và master M. Network partition tách A ra khỏi B và C:

• Phần 1 (chỉ A): A thấy master down → A muốn failover nhưng không có quorum (chỉ 1/2). Failover không xảy ra.
• Phần 2 (B + C): B và C đều thấy master down → đạt quorum (2/2) → failover tiến hành.

Sau khi network heal: A biết master mới, cập nhật state. Nếu master cũ quay lại, Sentinel tự reconfigure nó thành replica.

Kịch bản nguy hiểm hơn: Partition giữa client và master

Nếu một subset client vẫn kết nối được với master cũ trong khi Sentinel đã promote master mới:

• Master cũ vẫn nhận write trong partition window.
• Khi partition heal, master cũ trở thành replica và mất toàn bộ write đó (conflict).
• min-replicas-to-write (xem mục 15) giúp giảm thiểu data loss trong kịch bản này.

Config này đặt trên Redis master (không phải Sentinel):

# redis.conf (trên master)
min-replicas-to-write 1
min-replicas-max-lag 10

Ý nghĩa: Master từ chối nhận write nếu tại thời điểm đó không có ít nhất min-replicas-to-write replicas nào có lag nhỏ hơn hoặc bằng min-replicas-max-lag giây.

Với cấu hình trên: master reject write nếu không có replica nào connected và lag <= 10 giây. Điều này đảm bảo rằng mọi write đều đã được tối thiểu 1 replica acknowledge gần đây.

Trong kịch bản partition, khi master bị cô lập khỏi tất cả replica, nó sẽ tự ngừng nhận write sau tối đa min-replicas-max-lag giây, tránh write thêm data sẽ bị mất khi partition heal.

Tradeoff: nếu replica offline (deployment, restart), master cũng ngừng nhận write, gây outage không mong muốn. Cân nhắc kỹ với workload yêu cầu high availability writes.

Minimum viable: 3 machines

# Machine 1: Redis master + Sentinel A
# Machine 2: Redis replica + Sentinel B
# Machine 3: Redis replica + Sentinel C
#
# Co-locate OK cho nhỏ, nhưng nếu machine 1 chết:
# - Mất master → failover (đúng)
# - Mất Sentinel A → còn 2 Sentinel (đủ quorum)

Co-locate Sentinel với Redis là chấp nhận được nếu đủ 3 machines riêng biệt. Vấn đề chỉ xảy ra khi đặt tất cả Sentinel trên cùng một box.

Recommended: Multi-AZ

# AZ-1: Redis master + Sentinel A
# AZ-2: Redis replica + Sentinel B
# AZ-3: Redis replica + Sentinel C
#
# Khi AZ-1 down:
# - Sentinel B và C detect ODOWN → quorum đạt (2/3)
# - Promote replica ở AZ-2 hoặc AZ-3 lên master
# - System tiếp tục hoạt động dù mất 1 AZ

Multi-AZ là topology chuẩn cho production. Một AZ down không ảnh hưởng service, chỉ giảm redundancy tạm thời.

Sentinel-only machines

Với dataset lớn và Redis cần toàn bộ resource của machine, có thể chạy Sentinel trên các machine riêng (không có Redis). Sentinel rất nhẹ về tài nguyên — vài MB RAM là đủ.

• Không shard data: Sentinel chỉ xử lý failover, không phân tán data qua nhiều node. Toàn bộ dataset phải fit vào một instance.
• Single write endpoint: tất cả write vẫn đi qua một master duy nhất. Không scale-out write throughput được.
• Không thay thế Redis Cluster: khi dataset quá lớn hoặc write throughput vượt capacity của một node, cần Redis Cluster (bài 102).
• Redis Cluster không cần Sentinel: Cluster có cơ chế failover nội bộ. Sentinel dành cho kiến trúc single master + replicas.
• Data loss có thể xảy ra: replication là async. Khi master crash, các write chưa kịp replicate sẽ mất. min-replicas-to-write giảm nhưng không loại trừ hoàn toàn.
• Downtime ngắn là không thể tránh: 5–15s downtime trong failover là thực tế. Sentinel không đảm bảo zero-downtime, chỉ đảm bảo automatic recovery.

Chỉ 1 hoặc 2 Sentinel

1 Sentinel: không có quorum mechanism — không ai vote, failover không xảy ra. 2 Sentinel (even number): split-brain nguy hiểm — khi 1 Sentinel down, Sentinel còn lại không đủ majority để bầu leader. Luôn dùng số lẻ từ 3 trở lên.

Quorum sai

Quorum = 1 với 3 Sentinel: bất kỳ Sentinel nào cũng có thể kích hoạt failover một mình, kể cả khi nó bị cô lập khỏi master. Dễ false failover. Quorum = 3 với 3 Sentinel: cần tất cả 3 đồng ý — khi 1 Sentinel chết, không bao giờ đạt quorum, không failover được. Dùng majority.

Client không hỗ trợ Sentinel discovery

Client connect trực tiếp tới hardcode địa chỉ master. Sau failover, client tiếp tục connect địa chỉ cũ (giờ là replica hoặc dead node), mọi write thất bại cho đến khi restart application. Dùng Sentinel-aware client hoặc implement discovery layer.

Sentinel cùng box với Redis, tất cả trên 1 machine

Khi machine duy nhất chết, mất cả Redis lẫn Sentinel duy nhất. Không có gì để orchestrate failover. Phân tán sang ít nhất 3 machines.

Disable persistence trên master

Master không có RDB/AOF, khi crash và restart (không failover), data trắng. Replica detect master restart và sync lại — mang data trắng về, xóa toàn bộ data của replica. Luôn enable persistence trên master, hoặc ít nhất trên một replica.

Không test failover định kỳ

SENTINEL failover không được chạy định kỳ, phát hiện lúc incident thật rằng client không rediscover được (do config sai hoặc library version cũ). Test failover là phần bắt buộc của operational runbook.

• 3+ Sentinel, số lẻ: quorum = majority = ⌊N/2⌋ + 1.
• Multi-AZ distribution: mỗi AZ một Sentinel, tránh mất quorum khi 1 AZ down.
• Sentinel-aware client: không hardcode master address, dùng Sentinel discovery.
• Set replica-priority hợp lý: ưu tiên replica ở datacenter gần nhất, set priority 0 cho replica không nên promote.
• min-replicas-to-write cho critical data: chấp nhận reject write hơn là mất data trong partition.
• Subscribe Sentinel events: +switch-master, +odown để có alert kịp thời.
• Test failover định kỳ: chạy SENTINEL failover ít nhất mỗi tháng trong production maintenance window, log RTO thực tế.
• Document RPO/RTO: RPO (data loss) thực tế phụ thuộc replication lag tại thời điểm crash. RTO (recovery time) thực tế phụ thuộc down-after-milliseconds và client reconnect logic.
• Enable persistence: ít nhất AOF appendfsync everysec trên master và 1 replica.
• Monitor replica count: nếu Sentinel báo replica count = 0 lâu dài, có thể replication đã broken mà không ai biết.

Sentinel bổ sung automatic failover cho kiến trúc master-replica. Các điểm chính:

• Sentinel là distributed monitor, không lưu data, chạy trên port riêng (mặc định 26379).
• SDOWN = 1 Sentinel nhận định master down. ODOWN = quorum Sentinel đồng ý → kích hoạt failover.
• Failover: ODOWN → leader election → promote replica (theo priority, offset, run_id) → reconfigure replicas → notify clients.
• Client dùng SENTINEL get-master-addr-by-name để discover master hiện tại, không hardcode.
• 3+ Sentinel, số lẻ, multi-AZ là topology chuẩn production.
• Sentinel không shard data, không scale write — đó là vai trò của Redis Cluster.

Quiz

1. Vì sao 2 Sentinel không đủ an toàn? Điều gì xảy ra khi 1 trong 2 Sentinel mất kết nối tới master nhưng master vẫn hoạt động bình thường với client?
2. Sentinel chọn replica để promote dựa trên tiêu chí gì, theo thứ tự ưu tiên nào?
3. Sau failover, master cũ restart lại. Điều gì xảy ra với nó? Nó có thể tự lấy lại vị trí master không?
4. Client A hardcode địa chỉ master là 10.0.0.1:6379. Sau failover, master mới là 10.0.0.2:6380. Mô tả hành vi của Client A và cách khắc phục.
5. min-replicas-to-write 1 và min-replicas-max-lag 10 bảo vệ khỏi vấn đề gì? Tradeoff là gì khi replica duy nhất bị restart?

Đáp án gợi ý

1. Với 2 Sentinel, majority cần 2/2. Khi Sentinel A mất kết nối tới master (nhưng master vẫn sống), A muốn failover nhưng cần Sentinel B đồng ý. Nếu B không thấy master down, không đạt quorum. Nếu B cũng bị ảnh hưởng, 2/2 có thể sai dẫn tới false failover. Quan trọng hơn, khi 1 Sentinel chết vĩnh viễn, Sentinel còn lại không đủ majority để bầu leader (cần 2/2 nhưng chỉ có 1/2), failover bị kẹt hoàn toàn.
2. Theo thứ tự: (1) loại replica down hoặc lag quá cao, (2) replica-priority thấp nhất (0 = không bao giờ promote), (3) replication offset cao nhất (ít data loss nhất), (4) run_id nhỏ nhất lexicographically (tiebreaker).
3. Master cũ khi quay lại được Sentinel tự động reconfigure thành replica của master mới (REPLICAOF new_master_ip new_port). Nó không thể tự lấy lại vị trí master — phải failover lại hoặc can thiệp thủ công.
4. Client A tiếp tục kết nối 10.0.0.1:6379. Nếu master cũ đã bị demote thành replica, mọi write của A trả về READONLY error. Nếu master cũ dead, connection refused. A phải restart hoặc implement rediscovery. Khắc phục: dùng Sentinel-aware client, cung cấp danh sách Sentinel addresses thay vì hardcode master.
5. Bảo vệ khỏi: master bị cô lập (partition) tiếp tục nhận write mà không có replica, dẫn đến data mất khi partition heal và old master bị demote. Tradeoff: nếu replica duy nhất restart hoặc lag vượt 10s vì bất kỳ lý do nào, master từ chối write → downtime không liên quan tới failure thực sự.

Bài tiếp theo

Bài 102 đi vào Redis Cluster: hash slots, sharding data qua nhiều master, hash tags {} để group keys, CROSSSLOT errors, resharding, và cluster-aware clients.

Tham khảo

• Redis Docs — Sentinel
• Redis Docs — Lệnh SENTINEL
• Redis Docs — Sentinel Configuration
• redis-py Docs — Sentinel Client
• Redis Docs — Sentinel API
• Redis Docs — Example Sentinel Deployments