Failover Redis Cluster

Failover Redis Cluster — это механизм автоматического переключения ролей между узлами кластера Redis, обеспечивающий отказоустойчивость и непрерывность работы при выходе из строя одного или нескольких узлов. В контексте Redis Cluster, под failover понимается процесс, при котором один из реплик (slave-узлов) повышается до статуса мастера (master-узла) в случае недоступности последнего, что позволяет кластеру сохранять способность обрабатывать запросы на запись и чтение без вмешательства администратора.

Архитектура Redis Cluster

Redis Cluster представляет собой распределённую реализацию Redis, которая автоматически сегментирует данные (шардирование) по нескольким узлам. Кластер состоит из множества мастер-узлов (master nodes), каждый из которых отвечает за определённый диапазон хэш-слотов (hash slots). Всего в Redis Cluster определено 16 384 хэш-слота. Каждый мастер может иметь от 0 до нескольких реплик (replica nodes), которые являются точными копиями данных мастера.

Роли узлов

• Master-узел (мастер) — основной узел, обслуживающий запросы на запись и чтение для своего набора слотов. Каждый мастер владеет уникальным диапазоном слотов.
• Replica-узел (реплика) — резервный узел, который синхронизирует данные с мастером. Реплика не обслуживает запросы на запись (если не настроено специальное поведение), но может обслуживать запросы на чтение при включённой опции readonly. В случае отказа мастера реплика может быть повышена до мастера.

Процесс failover

Failover в Redis Cluster может быть инициирован автоматически (по обнаружению отказа мастера) или вручную (администратором). Основные этапы автоматического failover:

1. Обнаружение отказа — кластер использует механизм gossip-протокола для обмена информацией о состоянии узлов. Каждый узел периодически отправляет PING-сообщения другим узлам. Если узел не отвечает на PING в течение заданного времени (параметр cluster-node-timeout, по умолчанию 15000 мс), он считается подозрительным (PFAIL — possibly failed). Если большинство мастеров (или все мастера, в зависимости от конфигурации) подтверждают недоступность узла, он помечается как FAIL (definitively failed).

1. Выбор новой реплики — среди реплик, связанных с отказавшим мастером, запускается процесс выборов. Каждая реплика проверяет, что её данные актуальны (синхронизация с мастером не отстаёт более чем на заданное количество команд). Реплика, которая имеет наиболее свежие данные, получает приоритет. Если несколько реплик имеют одинаковую актуальность, выбор происходит на основе случайного тайм-аута.

1. Повышение реплики до мастера — выбранная реплика отправляет команду CLUSTER FAILOVER (в автоматическом режиме) и переключает свой статус на мастер. Она начинает обслуживать хэш-слоты, ранее принадлежавшие отказавшему мастеру. Другие реплики, связанные с этим мастером, переключаются на новый мастер.

1. Обновление конфигурации кластера — все узлы кластера получают обновлённую информацию о топологии через gossip-протокол. Клиенты, использующие Redis Cluster, также должны обновить свою карту слотов (slot map) для корректной маршрутизации запросов.

Время выполнения failover

Время автоматического failover зависит от cluster-node-timeout и задержек в сети. В типичной конфигурации (тайм-аут 15 секунд) процесс занимает от 15 до 30 секунд. Для критичных приложений рекомендуется настраивать более низкие значения тайм-аута, но это может увеличить количество ложных срабатываний.

Типы failover

Автоматический failover

Инициируется кластером при обнаружении отказа мастера. Требует, чтобы большинство мастеров (кворум) были доступны для голосования. Если кластер теряет более половины мастеров, автоматический failover невозможен, и кластер переходит в состояние недоступности для операций записи.

Ручной failover

Администратор может инициировать ручной failover с помощью команды CLUSTER FAILOVER. Это полезно для планового обслуживания, когда нужно заменить мастер без остановки обслуживания. Ручной failover может быть выполнен в нескольких режимах:

• force — принудительное переключение без проверки актуальности данных реплики.
• takeover — переключение без согласования с другими узлами, используется в аварийных ситуациях, когда кластер разделён (split-brain).
• default — плавное переключение, при котором мастер синхронизирует последние данные с репликой перед передачей управления.

Ограничения и риски

• Потеря данных — при асинхронной репликации (по умолчанию) реплика может не получить последние записи, если мастер выходит из строя до их отправки. Для минимизации потерь можно использовать синхронную репликацию (параметр wait), но это снижает производительность.
• Split-brain (разделение мозга) — в случае сетевого разделения кластера могут образоваться две независимые группы узлов, каждая из которых считает себя легитимной. Redis Cluster не имеет встроенного механизма разрешения split-brain, поэтому требуется ручное вмешательство.
• Зависимость от кворума — для автоматического failover необходимо, чтобы большинство мастеров были доступны. Если кластер состоит из 3 мастеров, отказ одного из них не нарушает работу, но отказ двух делает failover невозможным.

Практические рекомендации

• Минимальная конфигурация — для отказоустойчивости рекомендуется использовать не менее 3 мастеров и 3 реплик (по одной реплике на каждый мастер). Это позволяет пережить отказ одного мастера и одной реплики одновременно.
• Мониторинг — необходимо настроить мониторинг состояния кластера (например, через Redis Sentinel или внешние системы) для своевременного обнаружения проблем.
• Тестирование — регулярно проводить тесты failover в контролируемой среде для проверки корректности работы механизма.
• Настройка тайм-аутов — подбирать cluster-node-timeout в зависимости от задержек сети и требований к времени восстановления.

Сравнение с Redis Sentinel

Redis Sentinel — это отдельная система для обеспечения высокой доступности (HA) для одиночных экземпляров Redis (не кластеров). Sentinel также поддерживает автоматический failover, но работает на уровне отдельных мастер-реплика пар, а не распределённого кластера. В отличие от Redis Cluster, Sentinel не поддерживает шардирование данных. Для масштабируемых и отказоустойчивых систем с большими объёмами данных обычно используется Redis Cluster, а для небольших конфигураций — Redis Sentinel.

Источники

• Официальная документация Redis Cluster (redis.io/docs/latest/operate/oss_and_stack/management/scaling/)
• Redis Cluster Specification (redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/)
• Книга «Redis in Action» (Josiah L. Carlson, 2013)
• Статья «Redis Cluster: автоматический failover и отказоустойчивость» (Habr, 2020)