Настройка репликации Redis мастер-слейв

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

Принципы репликации мастер-слейв в Redis

Репликация в Redis основана на одностороннем асинхронном копировании данных с одного узла (мастер) на один или несколько других (слейвы). Каждый слейв подключается к мастеру как обычный клиент и запрашивает поток изменений. Это позволяет строить иерархические схемы: например, слейв может сам быть мастером для другого уровня реплик.
Данные передаются в виде команд, которые мастер выполняет — так называемый «командный подход» (command propagation). Это означает, что каждый write-запрос (SET, DEL, INCR и т.д.) реплицируется на все подключённые слейвы. Такая модель эффективна, но требует внимательного контроля за объемом операций записи, чтобы не перегружать сеть и дисковую подсистему.
Репликация не включает в себя автоматическое обнаружение отказов или переключение ролей. За это отвечает внешняя система, например, Redis Sentinel или оркестратор вроде Kubernetes. Тем не менее, базовая репликация — фундамент, без которого невозможна высокая доступность.

Как определить роль узла?

Чтобы узнать, является ли ваш экземпляр мастером или слейвом, выполните команду:

1. Подключитесь к Redis через redis-cli.
2. Выполните: INFO replication.
3. Найдите строку role:master или role:slave.

Если вы видите connected_slaves:N, где N — количество активных слейвов, значит, вы находитесь на мастер-узле.

Настройка мастер-сервера Redis

Перед тем как подключать слейвы, необходимо правильно настроить мастер. Основной файл конфигурации — redis.conf. Его расположение зависит от системы: обычно это /etc/redis/redis.conf или /usr/local/etc/redis.conf.
Первое, что нужно сделать — убедиться, что мастер принимает внешние подключения. По умолчанию Redis слушает только localhost. Чтобы разрешить подключение с других серверов:

• Найдите параметр bind 127.0.0.1 и замените его на bind 0.0.0.0 или конкретный IP-адрес интерфейса.
• Установите protected-mode no, если вы не используете пароль. Однако лучше включить аутентификацию.

Для безопасности обязательно задайте пароль:

requirepass ваш_надежный_пароль

Этот же пароль понадобится слейву для подключения. Также можно задать имя пользователя, если используется ACL (с версии 6.0).
После внесения изменений перезапустите Redis:

sudo systemctl restart redis-server

или

redis-cli shutdown && redis-server /path/to/redis.conf

Конфигурация слейв-сервера: шаг за шагом

Настройка слейва может быть выполнена двумя способами: через конфигурационный файл или динамически через redis-cli. Второй способ удобен для тестирования, но первый — более надёжный для продакшена.

Способ 1: Через redis.conf

Откройте конфигурационный файл слейва и добавьте:

slaveof <IP_мастера> <порт_мастера>

Например:

slaveof 192.168.1.10 6379

Также укажите пароль мастера:

masterauth ваш_надежный_пароль

Если используется ACL, укажите имя пользователя:

masteruser replicator

После этого перезапустите Redis на слейве.

Способ 2: Через команду REPLICAOF

Подключитесь к слейву через redis-cli и выполните:

REPLICAOF 192.168.1.10 6379

Затем установите пароль:

CONFIG SET masterauth "ваш_пароль"

Этот метод не сохраняет настройки после перезагрузки. Чтобы сделать их постоянными, используйте:

CONFIG REWRITE

— при условии, что Redis имеет права на запись в свой конфиг.

Механизм репликации: SYNC, PSYNC и частичная синхронизация

Изначально Redis использовал полную синхронизацию (SYNC), при которой слейв получал весь дамп данных от мастера. Это было медленно и ресурсоёмко. Начиная с версии 2.8, был внедрён PSYNC — протокол частичной синхронизации.
PSYNC работает следующим образом:

• При первом подключении слейв запрашивает полную копию данных (RDB-дамп).
• Мастер создаёт фоновый RDB-файл и отправляет его слейву.
• Одновременно мастер буферизует новые команды в replication backlog.
• После загрузки RDB слейв применяет накопленные команды из бэклога.

Если соединение прерывается на короткое время, слейв может запросить только недостающие данные, используя offset. Это возможно, если:

• Сбой был кратковременным.
• Replication backlog достаточно велик, чтобы вместить потерянные команды.
• Слейв и мастер ещё помнят session ID.

Размер бэклога задаётся параметром repl-backlog-size. По умолчанию — 1 МБ, что может быть недостаточно. Для высоконагруженных систем рекомендуется увеличить до 64–128 МБ.

Безопасность репликации: пароли, шифрование, ACL

Репликация без защиты — серьёзный риск. Даже внутри внутренней сети данные передаются в открытом виде. Вот ключевые меры безопасности:

• Аутентификация: всегда используйте requirepass и masterauth.
• ACL (Access Control List): начиная с Redis 6.0, можно создавать пользователей с ограниченными правами. Например, пользователь replicator с правами только на репликацию.
• Шифрование: Redis не поддерживает TLS по умолчанию. Используйте stunnel, sslh или прокси вроде nginx для шифрования трафика между мастером и слейвами.
• Сетевой уровень: настройте firewall, чтобы разрешить подключения только с IP-адресов слейвов.

Пример создания пользователя для репликации:

ACL SETUSER replicator on >password ~* +psync +replconf +ping

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

Мониторинг и диагностика репликации

Стабильная репликация требует постоянного наблюдения. Ключевая команда — INFO replication. Она показывает состояние всех реплик.
Основные метрики:

• master_repl_offset — текущее смещение на мастере.
• slave_repl_offset — смещение на слейве. Разница между ними — задержка репликации.
• seconds_behind_master — актуальна только для слейвов. Показывает, на сколько секунд отстаёт реплика.
• link_status — up/down. Показывает, подключён ли слейв.

Для автоматического мониторинга интегрируйте Redis в Prometheus с помощью Redis Exporter. Ключевые алерты:

• Слейв отключён более 30 секунд.
• Задержка репликации > 10 секунд.
• Master offset растёт, а slave — нет (признак зависания).

Также можно использовать команду:

ROLE

Она возвращает детальную информацию о роли узла и его репликах в формате массива.

Ручной и автоматический фейлувер: что делать при падении мастера

Redis не поддерживает автоматический фейлувер «из коробки». Если мастер падает, слейвы остаются в режиме read-only. Чтобы восстановить запись, нужно вручную или с помощью системы перевести один из слейвов в роль мастера.

Ручной фейлувер

На выбранном слейве выполните:

REPLICAOF NO ONE

Теперь он становится самостоятельным мастером. Обновите конфигурацию приложений, чтобы они писали в новый мастер. Остальные слейвы нужно переподключить к нему.

Автоматический фейлувер через Redis Sentinel

Sentinel — это отдельная служба, которая следит за состоянием мастеров и слейвов. При обнаружении отказа она автоматически выбирает нового мастера и перенастраивает остальные узлы.
Настройка Sentinel:

1. Запустите минимум три экземпляра Sentinel на разных серверах.
2. Настройте каждый через sentinel.conf:

sentinel monitor mymaster 192.168.1.10 6379 2
sentinel auth-pass mymaster ваш_пароль
sentinel down-after-milliseconds mymaster 5000

Параметр 2 — кворум: два Sentinel’а должны согласиться на фейлувер.

Лучшие практики и типовые ошибки

• Не используйте репликацию как единственную форму резервного копирования. RDB и AOF всё равно необходимы.
• Регулярно тестируйте фейлувер. Плановое отключение мастера помогает выявить проблемы в конфигурации.
• Следите за размером RDB. Большой дамп замедляет первоначальную синхронизацию новых слейвов.
• Используйте DNS или балансировщик для абстрагирования мастер-адреса. Это упрощает переключение при фейлувере.
• Не размещайте мастер и слейв на одном физическом сервере. При сбое железа вы потеряете всё.

Типовые ошибки:

• Забыть указать masterauth — слейв не сможет подключиться.
• Слишком маленький repl-backlog-size — постоянные полные пересинхронизации.
• Открытый порт 6379 в интернете — риск взлома и шифровальщиков.
• Несинхронизированное время на серверах — усложняет диагностику.

Экспертное мнение

Репликация мастер-слейв — это не про масштабирование записи, а про отказоустойчивость и распределение чтения. Если ваша нагрузка — 80% на чтение, слейвы помогут существенно разгрузить мастер. Но при преобладании записи стоит задуматься о шардировании.
Выбор между Sentinel и Cluster зависит от сложности системы. Для большинства проектов достаточно мастер-слейв + Sentinel. Cluster нужен, когда требуется горизонтальное масштабирование и управление тысячами ключей.
Важно понимать: репликация — это компромисс между согласованностью и доступностью. Redis следует модели AP (по классификации CAP), то есть при сетевых разрывах слейвы продолжают работать, но могут отставать. Для сценариев, где важна строгая согласованность, требуются дополнительные механизмы — например, проверка через quorum.

Вопросы и ответы

Заключение

Настройка репликации Redis по схеме мастер-слейв — обязательный этап построения отказоустойчивой и производительной системы. Правильно настроенная репликация обеспечивает защиту от потери данных, распределяет нагрузку на чтение и готовит инфраструктуру к аварийным ситуациям. Однако важно понимать её ограничения: отсутствие автоматического фейлувера, зависимость от сети и необходимость в дополнительных инструментах мониторинга.

• Всегда используйте аутентификацию и ограничивайте сетевой доступ.
• Настройте достаточный размер repl-backlog-size для минимизации полных синхронизаций.
• Интегрируйте мониторинг через INFO replication и внешние системы.
• Для автоматического управления используйте Redis Sentinel.
• Тестируйте сценарии отказа, чтобы быть готовым к реальным сбоям.