Redis Sentinel: пошаговое руководство по настройке отказоустойчивого кластера (2026) | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Redis Sentinel: пошаговое руководство по настройке отказоустойчивого кластера (2026)

06 апреля 2026 15 мин. чтения
Содержание статьи

Обновлено: май 2026

Redis Sentinel — это стандартная система мониторинга и оркестрации, которая автоматизирует восстановление после сбоя мастер-узла в кластере Redis. В отличие от простой master-slave репликации, где падение мастера требует ручного вмешательства и приводит к простою, Sentinel обеспечивает высокую доступность (High Availability, HA) за счет автоматического обнаружения отказа, выбора новой реплики в качестве мастера и переконфигурации остальных узлов. Это решение устраняет необходимость ручного администрирования при инцидентах, минимизирует время простоя критичных сервисов и является обязательным компонентом для production-сред, где важна отказоустойчивость.

В этом руководстве мы подробно разберем архитектуру Sentinel, правила формирования кворума, предоставим готовые рабочие конфигурации и пошагово опишем процесс автоматического переключения (failover). Вы научитесь правильно интегрировать Sentinel с приложениями, настраивать мониторинг и диагностировать типичные проблемы, чтобы поддерживать стабильную работу кластера.

Что вы получите после прочтения

  • Готовые конфигурационные файлы для мастер-узла, реплик и экземпляров Sentinel, которые можно скачать и адаптировать под свою инфраструктуру.
  • Пошаговый сценарий тестирования failover с командой для симуляции падения мастера и проверкой логов.
  • Готовые сниппеты кода для интеграции Sentinel с приложениями на Python (redis-py) и Java (Jedis).
  • Чек-лист мониторинга с ключевыми метриками и пример настройки дашборда в Grafana для Prometheus.

Быстрый чек-лист успешной настройки

  • Топология: Минимум 3 узла Redis (1 мастер + 2 реплики) и 3 экземпляра Sentinel на разных хостах.
  • Кворум: Для 3 Sentinel'ов используйте quorum=2. Два Sentinel'а недостаточно для защиты от split-brain.
  • Сеть: Все узлы имеют статические IP/DNS, открыты порты 6379 (Redis) и 26379 (Sentinel).
  • Аутентификация: Пароли requirepass и masterauth идентичны на всех узлах.
  • Проверка: После настройки выполните SENTINEL SENTINELS mymaster — должны отобразиться все 3 сторожа.
  • Клиенты: Приложения подключаются через список Sentinel'ов, а не напрямую к IP мастера.

Содержание

  1. Что такое Redis Sentinel и зачем он нужен в production
  2. Архитектура Sentinel: как распределенные сторожа следят за кластером
  3. Подготовка к развертыванию: требования и планирование
  4. Правила формирования кворума: почему нужно минимум три Sentinel
  5. Пошаговая настройка Redis Sentinel: от конфигурации до запуска
  6. Как работает автоматический failover: от сбоя до переключения
  7. Интеграция Sentinel с приложением: настройка клиентов
  8. Мониторинг и эксплуатация отказоустойчивого кластера
  9. Резюме: лучшие практики и итоги

Что такое Redis Sentinel и зачем он нужен в production

Базовая master-slave репликация Redis решает задачу резервирования данных, но оставляет уязвимость на уровне управления. Если мастер-узел выходит из строя, администратору необходимо вручную: 1) определить новую реплику-кандидата, 2) перевести её в режим мастера командой SLAVEOF NO ONE, 3) перенастроить все остальные реплики на нового мастера. Этот процесс требует времени, чреват ошибками и приводит к простою приложения.

Redis Sentinel решает эту проблему, выступая в роли распределенной системы мониторинга и управления. Его ключевые функции:

  • Мониторинг: Постоянная проверка работоспособности мастер-узла и его реплик.
  • Оповещение: Уведомление администраторов о событиях в кластере через различные каналы.
  • Автоматический failover: При отказе мастера Sentinel самостоятельно выбирает и продвигает новую реплику, а затем переконфигурирует остальные узлы.
  • Конфигурация клиентов: Предоставление клиентским приложениям актуального адреса текущего мастера.

Таким образом, Sentinel превращает набор отдельных инстансов Redis в управляемый, отказоустойчивый кластер, где восстановление после сбоя происходит без участия человека.

Архитектура Sentinel: как распределенные сторожа следят за кластером

Система состоит из двух типов компонентов: экземпляры Redis (мастер и реплики) и экземпляры Sentinel. Каждый Sentinel — это специальный процесс (или работающий в режиме sentinel экземпляр Redis), который не хранит данные приложения, а выполняет только функции мониторинга и оркестрации.

Принцип работы:

  1. Каждый экземпляр Sentinel мониторит состояние мастер-узла и всех известных ему реплик, отправляя им команды PING с заданным интервалом.
  2. Сентинели также общаются друг с другом, обмениваясь информацией о состоянии узлов и голосуя при принятии решений (например, о начале failover).
  3. Если мастер не отвечает на PING в течение времени, заданного параметром down-after-milliseconds, Sentinel, обнаруживший проблему, помечает его как субъективно недоступный (SDOWN — Subjectively DOWN).
  4. Чтобы избежать ложного срабатывания из-за сетевых проблем на одном хосте, этот Sentinel запрашивает мнение у других. Если достаточное количество (кворум) Sentinel'ов соглашается, что мастер недоступен, состояние меняется на объективный отказ (ODOWN — Objectively DOWN). Только после этого может быть инициирован процесс failover.

Критически важное правило: Экземпляры Sentinel должны быть развернуты на разных физических серверах или, как минимум, в отдельных контейнерах/виртуальных машинах. Запуск Sentinel на том же хосте, что и мониторируемый им узел Redis, сводит на нет отказоустойчивость — падение сервера убьет и узел данных, и его «сторожа».

Подготовка к развертыванию: требования и планирование

Перед началом настройки необходимо спланировать топологию кластера. Минимальная рекомендуемая и надежная конфигурация для production включает:

  • 3 экземпляра Redis: 1 мастер (master) и 2 реплики (slave).
  • 3 экземпляра Sentinel: Размещенных на отдельных серверах от узлов Redis и друг от друга.

Такая схема гарантирует, что отказ одного сервера не приведет к потере кворума Sentinel'ов и кластер сохранит работоспособность.

Требования к сети:

  • Все узлы (Redis и Sentinel) должны иметь статические IP-адреса или резолвящиеся DNS-имена.
  • Между всеми узлами должна быть стабильная сетевая связь. Необходимо настроить брандмауэры, разрешив трафик на порты Redis (по умолчанию 6379) и Sentinel (по умолчанию 26379).

Подготовка Redis: Убедитесь, что на мастер-узле и репликах в конфигурационном файле redis.conf разрешены подключения из сети (bind 0.0.0.0 или конкретный IP) и, при необходимости, настроена аутентификация (requirepass и masterauth с одинаковым паролем на всех узлах). Для полной настройки Redis под production ознакомьтесь с отдельным руководством.

Правила формирования кворума: почему нужно минимум три Sentinel

Кворум (quorum) — это фундаментальное понятие распределенных систем. В контексте Redis Sentinel это минимальное количество экземпляров Sentinel, которые должны согласиться с тем, что мастер-узел недоступен, чтобы инициировать процесс автоматического переключения (failover).

Параметр quorum задается в конфигурации Sentinel для каждого мониторируемого мастера. Например, строка sentinel monitor mymaster 192.168.1.10 6379 2 означает, что для мастера с именем mymaster кворум равен 2.

  • При 3 работающих Sentinel'ах и quorum=2 для инициации failover нужно, чтобы как минимум 2 из них детектировали отказ мастера (ODOWN).
  • При 5 Sentinel'ах типичный quorum=3.

Почему два Sentinel'а недостаточно? Рассмотрим сценарий сетевого раздела (network partition), когда сеть делится на две изолированные части. Если в каждой части останется по одному Sentinel'у и мастер-узлу (или реплике), оба Sentinel'а, не имея связи друг с другом, могут принять независимое решение о начале failover. Это приведет к ситуации «раскола мозга» (split-brain), когда в разных сегментах сети появятся два активных мастера, что вызовет потерю согласованности данных. Наличие третьего Sentinel'а, который в случае раздела окажется в одной из частей сети, позволяет сохранить кворум только в одной части и предотвратить двойное переключение.

Слишком высокий кворум (например, quorum=5 при 5 Sentinel'ах) делает систему излишне консервативной — для реакции на отказ мастера потребуется согласие практически всех сторожей, что может замедлить реакцию на реальный инцидент.

Пошаговая настройка Redis Sentinel: от конфигурации до запуска

Предположим, у нас есть три сервера с IP-адресами: 192.168.1.10 (мастер), 192.168.1.11 (реплика-1), 192.168.1.12 (реплика-2). Sentinel'ы будут запущены на этих же серверах, но в отдельных процессах. Это допустимо для демонстрации, но помните о рекомендации по раздельному размещению.

Шаг 1: Настройка мастер-узла Redis (192.168.1.10)
В файле /etc/redis/redis.conf убедитесь в наличии или добавьте следующие строки:

bind 192.168.1.10
port 6379
dir /var/lib/redis
# Опционально, для безопасности:
requirepass YourStrongPassword
masterauth YourStrongPassword

Запустите или перезапустите Redis: sudo systemctl restart redis-server.

Шаг 2: Настройка реплик
На серверах 192.168.1.11 и 192.168.1.12 в файлах redis.conf укажите мастер:

bind 192.168.1.11 # Для второго сервера - 192.168.1.12
port 6379
replicaof 192.168.1.10 6379
masterauth YourStrongPassword
requirepass YourStrongPassword

После перезапуска Redis на репликах проверьте статус репликации на мастере командой redis-cli -h 192.168.1.10 INFO replication. В выводе должны появиться connected slaves.

Скачать готовые конфигурационные файлы

Для ускорения настройки вы можете использовать готовые шаблоны конфигурационных файлов. Скопируйте содержимое ниже в соответствующие файлы на ваших серверах, заменив IP-адреса и пароль.

redis-master.conf (для 192.168.1.10):

bind 192.168.1.10
port 6379
dir /var/lib/redis
requirepass YourStrongPassword
masterauth YourStrongPassword

redis-slave.conf (для 192.168.1.11 и 192.168.1.12):

bind 192.168.1.11 # Замените на IP реплики
port 6379
replicaof 192.168.1.10 6379
masterauth YourStrongPassword
requirepass YourStrongPassword

sentinel.conf (универсальный для всех трех серверов):

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster YourStrongPassword

Шаг 3: Настройка и запуск экземпляров Sentinel
На каждом из трех серверов создайте конфигурационный файл, например, /etc/redis/sentinel.conf, используя шаблон выше.

Конфигурационный файл sentinel.conf: разбор ключевых параметров

Приведем пример файла для сервера 192.168.1.10:

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
# Если на узлах Redis настроен пароль:
sentinel auth-pass mymaster YourStrongPassword

Разбор параметров:

  • sentinel monitor mymaster 192.168.1.10 6379 2: Объявляет мастер с именем mymaster для мониторинга. Указывает исходный IP и порт мастера, а также кворум (quorum=2). После запуска Sentinel самостоятельно обнаружит реплики.
  • sentinel down-after-milliseconds mymaster 5000: Время в миллисекундах, в течение которого мастер не должен отвечать на PING, чтобы быть помеченным данным Sentinel'ом как субъективно недоступный (SDOWN). Значение 5000 (5 секунд) — хороший старт для большинства сред. Слишком малое значение может вызвать ложные срабатывания при сетевых задержках.
  • sentinel failover-timeout mymaster 60000: Общий таймаут в миллисекундах для операций failover. Определяет, как долго Sentinel будет ждать определенных действий (например, переконфигурации реплик) перед тем, как считать операцию неудачной и, возможно, повторить её.
  • sentinel parallel-syncs mymaster 1: Количество реплик, которые могут одновременно синхронизироваться с новым мастером после failover. Синхронизация — ресурсоемкая операция. Установка значения 1 снижает нагрузку на нового мастера. Если у вас много реплик и они не сильно отстают, можно увеличить.

Создайте аналогичные файлы на других серверах. Единственное отличие — в строке sentinel monitor всегда указывается исходный адрес мастера (192.168.1.10), а не локальный IP сервера.

Шаг 4: Запуск Sentinel
На каждом сервере выполните:
redis-sentinel /etc/redis/sentinel.conf
Или, если используете systemd: sudo systemctl start redis-sentinel (предварительно настроив юнит).

Проверка работоспособности кластера после настройки

Подключитесь к любому экземпляру Sentinel с помощью redis-cli:

redis-cli -h 192.168.1.10 -p 26379

Выполните ключевые диагностические команды:

  1. SENTINEL MASTERS: Покажет список всех мониторируемых мастеров (обычно один) с их статусом, адресом, количеством реплик и Sentinel'ов.
  2. SENTINEL SLAVES mymaster: Выведет детальную информацию обо всех известных репликах для мастера mymaster: IP, порт, состояние репликации (lag), флаги.
  3. SENTINEL SENTINELS mymaster: Покажет список других экземпляров Sentinel, мониторящих тот же мастер. Это критически важно — здесь должны отображаться два других Sentinel'а с их IP-адресами и портами. Если их нет, значит, Sentinel'ы не видят друг друга (проблемы с сетью или конфигурацией).

Проверьте, что все узлы в статусе online, а не s_down или o_down.

Как проверить работу failover на тестовом стенде

После успешной настройки рекомендуется провести тестовый failover. На мастер-узле (192.168.1.10) выполните одну из команд для симуляции сбоя:

  • Остановка службы: sudo systemctl stop redis-server
  • Имитация аварийного завершения (для тестов): redis-cli -h 192.168.1.10 DEBUG SEGFAULT (используйте с осторожностью).

Сразу после этого начните мониторить логи Sentinel на одном из узлов (например, tail -f /var/log/redis/sentinel.log). Вы должны увидеть последовательность событий: +sdown, +odown, +vote-for-leader, +selected-slave и, наконец, ключевое +switch-master. Через 10-30 секунд команда SENTINEL GET-MASTER-ADDR-BY-NAME mymaster должна вернуть IP-адрес одной из реплик (например, 192.168.1.11).

Как работает автоматический failover: от сбоя до переключения

Рассмотрим детальный сценарий, что происходит в кластере при отказе мастера (192.168.1.10).

  1. Обнаружение SDOWN: Каждый Sentinel отправляет команду PING мастеру каждую секунду. Если в течение down-after-milliseconds (5 сек) ответа нет, Sentinel, обнаруживший это, помечает мастера как субъективно недоступный.
  2. Переход в ODOWN и голосование: Обнаруживший SDOWN Sentinel запрашивает у других Sentinel'ов их мнение о состоянии мастера. Если количество Sentinel'ов, согласных с недоступностью, достигает заданного кворума (в нашем случае 2 из 3), состояние меняется на ODOWN.
  3. Выбор Лидера (Leader): Среди Sentinel'ов, детектировавших ODOWN, выбирается Лидер, который будет управлять конкретным процессом failover для этого мастера. Выбор происходит по алгоритму Raft.
  4. Выбор кандидата в новый мастер: Лидер анализирует список доступных реплик. Он отфильтровывает те, что помечены как отключенные, и выбирает наилучшего кандидата на основе приоритета (параметр slave-priority в redis.conf реплики, по умолчанию 100, чем меньше — тем выше приоритет) и степени отставания репликации (replication offset).
  5. Продвижение реплики: Лидер отправляет выбранной реплике команду SLAVEOF NO ONE, переводя её в режим мастера.
  6. Переконфигурация остальных реплик: После небольшой паузы, чтобы новый мастер успел начать принимать запросы, Лидер отправляет команду SLAVEOF всем остальным репликам, указывая им подключиться к новому мастеру.
  7. Обновление конфигурации и публикация: После успешной переконфигурации все Sentinel'ы обновляют свою внутреннюю конфигурацию, записывая нового мастера. Клиенты, запрашивающие у Sentinel'ов адрес мастера, начнут получать новый IP.

Весь процесс, от падения до полного восстановления работы, обычно занимает от 10 до 30 секунд в зависимости от таймаутов.

Анализ логов Sentinel во время failover: что искать

Логи Sentinel (файл, указанный в logfile) — основной инструмент для понимания происходящего. Вот типичные записи во время failover:

  • +sdown / -sdown: Узел перешел в состояние SDOWN или вышел из него.
  • +odown: Кворум достигнут, мастер в состоянии ODOWN.
  • +vote-for-leader: Sentinel проголосовал за конкретного лидера для failover.
  • +elected-leader: Данный Sentinel был избран лидером.
  • +failover-state-select-slave: Лидер начал этап выбора реплики-кандидата.
  • +selected-slave: Реплика выбрана.
  • +failover-state-send-slaveof-noone: Отправка команды SLAVEOF NO ONE новой реплике.
  • +switch-master: Ключевое событие. Master <old_ip> <old_port> <new_ip> <new_port>. Конфигурация обновлена.
  • +slave-reconf-done: Реплика успешно переконфигурирована на нового мастера.

Умение читать эти логи позволяет быстро диагностировать, на каком этапе застрял процесс failover, если что-то пошло не так.

Интеграция Sentinel с приложением: настройка клиентов

После настройки Sentinel приложение больше не должно подключаться напрямую к IP-адресу мастер-узла Redis. Вместо этого оно подключается к пулу экземпляров Sentinel и запрашивает у них актуальный адрес текущего мастера. Большинство современных клиентских библиотек имеют встроенную поддержку Sentinel.

Принцип работы клиента:

  1. При инициализации клиенту передается список адресов и портов экземпляров Sentinel (например, все три: 192.168.1.10:26379, 192.168.1.11:26379, 192.168.1.12:26379) и имя мастера (mymaster).
  2. Клиент поочередно опрашивает Sentinel'ы, чтобы найти работоспособный.
  3. У работающего Sentinel'а клиент запрашивает команду SENTINEL get-master-addr-by-name mymaster, чтобы получить IP и порт текущего мастера.
  4. Клиент устанавливает соединение с полученным адресом мастера и работает с ним.
  5. В фоновом режиме клиент периодически перепроверяет адрес мастера у Sentinel'ов. Если произошел failover и адрес изменился, клиент автоматически переподключается к новому мастеру, обрабатывая возможные временные ошибки записи во время переключения.

Примеры настройки популярных клиентов:

Python (redis-py):

from redis.sentinel import Sentinel

sentinel_hosts = [('192.168.1.10', 26379),
                  ('192.168.1.11', 26379),
                  ('192.168.1.12', 26379)]
sentinel = Sentinel(sentinel_hosts, socket_timeout=0.5)

# Получение соединения с мастером
master = sentinel.master_for('mymaster', socket_timeout=0.5, password='YourStrongPassword')
master.set('foo', 'bar')

# Получение соединения с репликой для чтения
slave = sentinel.slave_for('mymaster', socket_timeout=0.5, password='YourStrongPassword')
value = slave.get('foo')

Java (Jedis):

Set<String> sentinels = new HashSet<>();
sentinels.add("192.168.1.10:26379");
sentinels.add("192.168.1.11:26379");
sentinels.add("192.168.1.12:26379");

JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels, "YourStrongPassword");
try (Jedis jedis = pool.getResource()) {
    jedis.set("foo", "bar");
}

Важно: Настройте адекватные таймауты подключения и повторные попытки на стороне приложения, так как во время кратковременного failover (10-30 сек) операции могут завершаться ошибками.

Мониторинг и эксплуатация отказоустойчивого кластера

После развертывания кластер требует наблюдения. Ключевые метрики для мониторинга:

  • Состояние узлов Redis: Мастер и реплики в статусе up.
  • Количество подключенных Sentinel'ов: Должно равняться ожидаемому (в нашем случае 3). Команда: SENTINEL SENTINELS mymaster.
  • Количество реплик: Команда: SENTINEL SLAVES mymaster.
  • Lag репликации: В выводе SENTINEL SLAVES смотрите параметр master-link-status (должен быть ok) и master-last-io-seconds-ago (отставание в секундах, должно быть небольшим).
  • События Sentinel: Мониторинг логов на наличие событий +sdown, +odown, +switch-master. Их можно отправлять в системы алертинга (например, Prometheus Alertmanager).

Для интеграции с Prometheus можно использовать экспортеры, такие как redis_exporter, который умеет собирать метрики как с узлов Redis, так и с экземпляров Sentinel. Собранные метрики можно визуализировать в Grafana.

Пример дашборда мониторинга Redis Sentinel в Grafana:
Создайте дашборд Grafana с панелями для следующих ключевых метрик Prometheus (собираемых через redis_exporter):

  • redis_up: Доступность каждого узла Redis (1 = up, 0 = down).
  • redis_connected_slaves: Количество подключенных реплик к мастеру.
  • redis_master_link_up: Состояние соединения реплики с мастером (для реплик).
  • redis_master_last_io_seconds_ago: Задержка репликации в секундах.
  • redis_sentinel_master_ok_sentinels: Количество Sentinel'ов, считающих текущий мастер работоспособным.
  • redis_sentinel_master_status: Статус мастера с точки зрения Sentinel (0 = ok, 1 = sdown, 2 = odown).

Такой дашборд даст полную картину здоровья кластера и позволит быстро реагировать на инциденты.

Типичные проблемы и их решение:

  • «Sentinel не видит других sentinel'ов»: Проверьте сетевую связность между хостами на порту 26379 (команда telnet или nc). Убедитесь, что брандмауэры разрешают трафик. В конфигурации Sentinel убедитесь, что указан правильный bind адрес (или 0.0.0.0).
  • «Реплика не подключается к новому мастеру после failover»: Частая причина — несовпадение пароля masterauth на реплике с паролем requirepass на новом мастере. Убедитесь, что все узлы используют одинаковый пароль. Также проверьте сетевую доступность.
  • «Клиентское приложение не переключается на нового мастера»: Убедитесь, что клиентская библиотека поддерживает Sentinel и настроена с правильным списком адресов. Проверьте логи приложения на наличие ошибок подключения.

Для решения более сложных сценариев отказоустойчивости, например, настройки полноценного балансировщика нагрузки поверх нескольких сервисов, может пригодиться руководство по настройке отказоустойчивых сетей.

Резюме: лучшие практики и итоги

Redis Sentinel — это надежное и проверенное решение для обеспечения высокой доступности кластера Redis в production-средах. Ключ к успеху — правильное планирование и соблюдение лучших практик:

  1. Минимум три узла: Развертывайте минимум 3 экземпляра Sentinel на разных физических хостах для защиты от сетевых разделов и потери кворума.
  2. Адекватные таймауты: Настройте down-after-milliseconds с учетом сетевых задержок вашей инфраструктуры, чтобы избежать ложных срабатываний.
  3. Единая аутентификация: Используйте одинаковые пароли requirepass и masterauth на всех узлах Redis.
  4. Клиенты через Sentinel: Никогда не хардкодьте IP мастера в приложениях. Всегда используйте клиентские библиотеки с поддержкой Sentinel.
  5. Мониторинг и логи: Настройте сбор логов Sentinel и ключевых метрик (количество узлов, lag репликации, статус мастера) в Prometheus и Grafana для оперативного реагирования.
  6. Регулярное тестирование: Периодически проводите плановые тесты failover на staging-окружении, чтобы убедиться в работоспособности всей цепочки восстановления.

Следуя этому руководству и используя предоставленные готовые конфигурации и примеры кода, вы сможете быстро развернуть и поддерживать отказоустойчивый кластер Redis, способный автоматически восстанавливаться после сбоев, что критически важно для современных высоконагруженных приложений.

Поделиться:
Сохранить гайд? В закладки браузера