Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps

Руководство по настройке репликации Redis «ведущий-ведомый»

Настройте репликацию Redis «ведущий-ведомый» с помощью replicaof, аутентификации, мониторинга и проверок безопасности в производственной среде.

Руководство по настройке репликации Redis «ведущий-ведомый».

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

Это руководство показывает, как настроить репликацию Redis «ведущий-ведомый», проверить, что синхронизация работает, и избежать распространенных ошибок, которые раскрывают Redis или оставляют ведомые незаметно устаревшими.

Понимание основ репликации Redis

Репликация Redis является асинхронной (то есть ведущий не ждет подтверждения от ведомого о записи), что обеспечивает высокую производительность. Она работает в основном через две фазы: начальную синхронизацию и непрерывную синхронизацию.

Полная синхронизация (SYNC)

Когда ведомый впервые подключается к ведущему или после перерыва в сети, который предотвращает частичную ресинхронизацию, происходит полная синхронизация:

  1. Ведомый отправляет команду PSYNC ведущему.
  2. Ведущий запускает фоновый процесс сохранения для создания файла снимка RDB (.rdb).
  3. Ведущий буферизирует все новые команды записи, полученные во время создания RDB.
  4. После завершения файла RDB ведущий отправляет его ведомому.
  5. Ведомый загружает файл RDB в память.
  6. Наконец, ведущий отправляет все буферизированные команды записи ведомому для наверстывания.

Частичная ресинхронизация (PSYNC)

Redis 2.8+ поддерживает частичную ресинхронизацию. Если связь между ведущим и ведомым ненадолго прерывается, ведомый может запросить только недостающие команды с момента разрыва связи, используя буфер журнала репликации (настраиваемый циклический буфер на ведущем).

Предварительные требования и настройка

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

Для этого руководства мы предполагаем следующую настройку:

Экземпляр Роль IP-адрес Порт Файл конфигурации
Ведущий Ведущий 192.168.1.100 6379 redis-primary.conf
Ведомый 1 Ведомый 192.168.1.101 6380 redis-replica-1.conf

Шаг 2.1: Настройка ведущего экземпляра

Убедитесь, что ваш ведущий экземпляр готов принимать соединения от ведомых и настроен на управление сохранением (RDB или AOF), если это требуется для стабильности самого ведущего.

Критические настройки ведущего:

  1. Привязка: Убедитесь, что ведущий привязан к публичному IP-адресу или 0.0.0.0, если он работает на нескольких машинах. При использовании брандмауэров убедитесь, что порт 6379 открыт для IP-адресов ведомых.
  2. Сохранение: Хотя это не является строго обязательным для самой репликации, настоятельно рекомендуется включить RDB/AOF для сохранения данных ведущего.
# redis-primary.conf
port 6379
bind 0.0.0.0 # Привязка ко всем интерфейсам (необходимо для внешних ведомых)
# Включить сохранение RDB
save 900 1
save 300 10
save 60 10000

Шаг 2.2: Настройка ведомого экземпляра

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

Критические настройки ведомого:

  1. Порт: Используйте другой порт, если работаете на одной машине.
  2. Директива репликации: Используйте replicaof или slaveof (устаревшее название).
# redis-replica-1.conf
port 6380

# *** Основная конфигурация репликации ***
replicaof 192.168.1.100 6379

# Убедитесь, что ведомые доступны только для чтения (по умолчанию с Redis 5)
replica-read-only yes

# Рекомендуется отключить сохранение на ведомых, если HA обрабатывается Sentinel/Cluster
# Если сохранение необходимо для быстрого перезапуска, оставьте его включенным.
save ""

Примечание: Если ведущий требует пароль, настройте ведомого с помощью masterauth <password>. В Redis 6 и более поздних версиях с настройками ACL также настройте masteruser, когда пользователь репликации не является пользователем по умолчанию.

Методы реализации

Вы можете реализовать репликацию, отредактировав файл конфигурации и перезапустив сервер, или динамически, выполнив команду REPLICAOF из redis-cli.

Метод 3.1: Файл конфигурации (рекомендуется для производства)

После обновления redis-replica-1.conf, как показано выше, запустите оба экземпляра:

# Запуск ведущего
redis-server redis-primary.conf

# Запуск ведомого 1
redis-server redis-replica-1.conf

При запуске Ведомый 1 немедленно попытается подключиться к ведущему на 192.168.1.100:6379 и начнет процесс синхронизации.

Метод 3.2: Динамическая конфигурация

Если экземпляр Redis уже запущен, и вы хотите преобразовать его в ведомого без перезапуска, выполните REPLICAOF через redis-cli.

  1. Подключитесь к экземпляру, который вы хотите преобразовать в ведомого (работает на порту 6380 в нашем примере):

    redis-cli -p 6380

  2. Выполните команду репликации:

    127.0.0.1:6380> replicaof 192.168.1.100 6379
OK

Экземпляр на порту 6380 удалит все предыдущие данные и инициирует полную синхронизацию (SYNC) с новым ведущим.

⚠️ Предупреждение: Отключение репликации

Чтобы превратить ведомого обратно в автономный ведущий экземпляр, выполните replicaof no one на этом экземпляре.

4. Мониторинг статуса репликации

Мониторинг статуса соединения жизненно важен для обеспечения согласованности данных. Используйте команду INFO replication через redis-cli как на ведущем, так и на ведомом.

4.1 Проверка статуса ведущего

Подключитесь к ведущему (6379) и проверьте, сколько ведомых подключено и их статус:

redis-cli -p 6379 INFO replication

Ожидаемый фрагмент вывода (Ведущий):

# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.101,port=6380,state=online,offset=2048,lag=0
master_replid:a9b1c2...
master_replid2:000000...
master_repl_offset:2048
  • role:master подтверждает его роль.
  • connected_slaves:1 подтверждает, что ведомый виден.
  • state=online — желаемое устойчивое состояние.
  • lag=0 или низкое значение означает, что ведомый быстро отвечает. Репликация Redis все еще асинхронна, поэтому это не гарантия нулевой потери данных.

4.2 Проверка статуса ведомого

Подключитесь к ведомому (6380) и проверьте статус связи с ведущим:

redis-cli -p 6380 INFO replication

Ожидаемый фрагмент вывода (Ведомый):

# Replication
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:up
master_sync_in_progress:0
slave_priority:100
slave_read_only:1
  • role:slave подтверждает его роль.
  • master_link_status:up подтверждает, что соединение активно и здорово.
  • master_sync_in_progress:0 означает, что начальная синхронизация завершена.

Лучшие практики и оптимизация репликации

5.1 Режим только для чтения на ведомых

По умолчанию ведомые доступны только для чтения (replica-read-only yes). Это критически важный механизм безопасности. Попытка записи на ведомого приведет к ошибке, обеспечивая согласованность данных в кластере.

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

5.2 Оптимизация времени синхронизации

Если ваш набор данных очень большой, начальный процесс SYNC может быть медленным. Учтите следующие факторы:

  1. Пропускная способность сети: Убедитесь в достаточной пропускной способности между ведущим и ведомыми для передачи RDB.
  2. Генерация RDB: Ведущему требуется ресурсы ЦП и дисковый ввод-вывод для создания файла RDB. Убедитесь, что на сервере есть доступные ресурсы во время синхронизации.
  3. Отключение сохранения на диске на ведомых (опционально): Если ведущий обрабатывает все сохранение, а ведомый используется только для масштабирования чтения, установка save "" на ведомом позволяет избежать накладных расходов на ввод-вывод при записи файлов RDB, ускоряя перезапуск.

5.3 Безопасность и конфигурация сети

Крайне важно, чтобы ведущий не открывал публично свой порт репликации (6379 или другой) в интернет. Настройте правила брандмауэра, чтобы разрешить трафик репликации только с назначенных IP-адресов серверов ведомых.

5.4 Использование ведомых для масштабирования чтения

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

Что делать дальше

Настройка репликации Redis «ведущий-ведомый» необходима для создания отказоустойчивых высокопроизводительных приложений. Правильно настроив директиву replicaof и регулярно отслеживая статус связи с помощью INFO replication, вы создаете основу для высокой доступности и эффективного масштабирования чтения.

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