Что делает Redis Sentinel

От /

В контексте Redis, Sentinel — это система наблюдения и автоматического переключения Redis на резервный сервер при отказе основного.

Проще говоря, Sentinel отвечает не за хранение данных, а за то, чтобы Redis-кластер типа master + replicas продолжал работать, если master умер.

Sentinel выполняет четыре основные функции.

1. Следит за Redis-серверами

Sentinel регулярно проверяет:

  • доступен ли master;
  • доступны ли replicas;
  • доступны ли другие Sentinel-инстансы.

Упрощённо:

Sentinel → PING → Redis master
Sentinel → PING → Redis replica

Если Redis перестаёт отвечать, Sentinel начинает считать его подозрительным.

2. Определяет, действительно ли master упал

Здесь есть два состояния.

SDOWN: Subjectively Down

Один Sentinel решил:

Я не могу достучаться до master.

Это ещё не означает, что master действительно признан мёртвым всей системой. Возможно, проблема только у этого Sentinel или в сетевом соединении между ними.

ODOWN: Objectively Down

Несколько Sentinel-инстансов согласились:

Да, master действительно недоступен.

Для этого используется параметр quorum.

Например:

quorum = 2

Это означает, что минимум два Sentinel должны признать master недоступным.

3. Выполняет failover

Если master признан недоступным, Sentinel:

  1. выбирает одну из replicas;
  2. повышает её до нового master;
  3. перенастраивает остальные replicas на новый master;
  4. сообщает клиентам, где теперь находится master.

Было:

Redis A — master
Redis B — replica
Redis C — replica

Redis A упал.

Стало:

Redis A — недоступен
Redis B — новый master
Redis C — replica Redis B

Если Redis A потом вернётся, он обычно будет подключён уже как replica нового master.

4. Сообщает клиентам адрес текущего master

Клиент не должен жёстко подключаться к конкретному Redis-серверу:

redis-a:6379

Вместо этого клиент знает адреса Sentinel и имя master-группы:

Sentinel 1
Sentinel 2
Sentinel 3

master name: mymaster

Клиент спрашивает у Sentinel:

Где сейчас master для mymaster?

Sentinel возвращает актуальный адрес.

Это важно, потому что после failover адрес master меняется.

Типичная схема

                 ┌─────────────────┐
                 │     Client      │
                 └────────┬────────┘
                          │
               спрашивает адрес master
                          │
       ┌──────────────────┼──────────────────┐
       │                  │                  │
┌──────▼──────┐    ┌──────▼──────┐    ┌──────▼──────┐
│ Sentinel 1  │    │ Sentinel 2  │    │ Sentinel 3  │
└─────────────┘    └─────────────┘    └─────────────┘
       │                  │                  │
       └──────────────────┼──────────────────┘
                          │ наблюдение
                 ┌────────▼────────┐
                 │ Redis master A  │
                 └───────┬─────────┘
                         │ replication
              ┌──────────┴──────────┐
              │                     │
     ┌────────▼────────┐   ┌────────▼────────┐
     │ Redis replica B │   │ Redis replica C │
     └─────────────────┘   └─────────────────┘

Обычно используют не менее трёх Sentinel-инстансов, чтобы решение об отказе принималось большинством, а не одним наблюдателем.

Sentinel не хранит данные

Это ключевое различение.

Redis master / replica → хранят данные
Sentinel               → следит и управляет переключением

Sentinel не является:

  • отдельным хранилищем;
  • прокси для всех Redis-запросов;
  • заменой replication;
  • заменой Redis Cluster.

Sentinel и replication

Обычная Redis replication сама по себе выглядит так:

master → replica

Если master упал, replica не становится master автоматически. Кто-то должен:

  • обнаружить отказ;
  • выбрать replica;
  • повысить её;
  • перенастроить систему.

Именно это делает Sentinel.

То есть:

Replication = создание копий данных
Sentinel    = обнаружение отказа и автоматический failover

Sentinel и Redis Cluster

Это разные архитектуры.

Sentinel

Используется схема:

один master + replicas

Все данные находятся на одном master. Реплики содержат копии этих же данных.

Sentinel обеспечивает высокую доступность, но не распределяет данные по нескольким master.

Redis Cluster

Данные разделены между несколькими master по hash slots:

Master A → часть ключей
Master B → часть ключей
Master C → часть ключей

Redis Cluster решает сразу две задачи:

  • sharding;
  • high availability.

Sentinel в первую очередь решает только high availability.

Что Sentinel не гарантирует

Sentinel не превращает Redis в систему со строгой гарантией отсутствия потерь.

Redis replication обычно асинхронная.

Возможна ситуация:

  1. клиент записал значение в master;
  2. master подтвердил запись;
  3. master упал до передачи записи replica;
  4. replica стала новым master;
  5. подтверждённой записи на новом master нет.

То есть автоматический failover возможен, но небольшое окно потери последних записей остаётся.

Минимальный конфиг Sentinel

Пример sentinel.conf:

port 26379

sentinel monitor mymaster redis-master 6379 2

sentinel down-after-milliseconds mymaster 5000

sentinel failover-timeout mymaster 60000

sentinel parallel-syncs mymaster 1

Главная строка:

sentinel monitor mymaster redis-master 6379 2

Она означает:

mymaster       → логическое имя master-группы
redis-master   → hostname master
6379           → порт Redis
2              → quorum

Sentinel обычно запускается на порту:

26379

В одной формуле

Redis Sentinel =
мониторинг Redis
+ согласованное обнаружение отказа
+ выбор новой replica
+ автоматический failover
+ обнаружение клиентами нового master

То есть Sentinel — это диспетчер аварийного переключения для Redis replication. Он не перевозит данные сам, а следит, кто сейчас является главным, и меняет главного, когда прежний исчезает.

Subscribe
Прокрутить вверх