Redis Sentinel
Тема дорожной карты · Redis
Redis Sentinel — это система высокой доступности, отслеживающая первичные и реплицируемые узлы Redis, автоматически продвигающая реплику до первичного при недоступности последнего и уведомляющая клиентов об изменениях топологии. Для развёртывания Sentinel требуется минимум три процесса Sentinel для формирования кворума — количества Sentinel, которые должны согласиться о недоступности первичного перед инициированием переключения при сбое. Sentinel настраиваются строкой sentinel monitor mymaster 127.0.0.1 6379 2 в sentinel.conf, задающей адрес первичного и размер кворума. При переключении Sentinel выбирает реплику с наименьшим slave-priority и наиболее актуальным смещением репликации для продвижения, затем перенастраивает оставшиеся реплики для следования новому первичному. Клиенты Redis, использующие клиентские библиотеки с поддержкой Sentinel (например, класс Sentinel в redis-py или JedisSentinelPool в Jedis), автоматически переподключаются к новому первичному после переключения без ручного вмешательства.
Как это работает
Redis Sentinel даёт автоматический failover для не-cluster Redis-деплоев. Sentinel-процесс мониторит master + реплики; если master лёг (quorum-согласие), Sentinel промоутит реплику + переконфигурирует клиентов. Клиенты подключаются к Sentinel чтобы узнать текущего master ("спросите Sentinel, кто primary сейчас"). Типичный setup: 3 Sentinel (нечётное число для quorum) + 1 master + 1-2 реплики на разных хостах/зонах.
Когда применять
Sentinel — когда хотите HA без операционной сложности Cluster: один датасет, влезает в одну ноду, нужен только failover. Для данных > одного хоста — Cluster. Для managed Redis cloud-провайдер сам обрабатывает failover через свою инфру — Sentinel сами не настраиваете. Sentinel всегда на разных failure domain (хосты, стойки, зоны).
Типичные ошибки
Ловушки Redis Sentinel: 2 Sentinel (нет quorum при split-brain — нужно 3+); Sentinel на одном хосте с Redis (потеря одного хоста уносит обоих); не тестируют failover-путь (Sentinel, никогда не failover-ивший — просто работающий процесс); клиенты, навсегда закешировавшие master endpoint (после failover говорят с репликой, которая отвечает READONLY).