Redis sentinel что это

Русские Блоги

Redis Sentinel и Redis Cluster

Введение

Сегодня, с быстрым развитием Интернета, требования к стойкости к давлению прикладных систем становятся все выше и выше. Традиционный прикладной уровень + база данных больше не может соответствовать текущим потребностям. Поэтому появилось большое количество баз данных в памяти и баз данных Nosql, среди которых redis, memcache, mongodb, hbase и т. Д., Которые широко используются для повышения пропускной способности системы, поэтому правильное использование кэша является основным навыком для разработки. Эта статья в основном знакомит с различием и использованием Redis Sentinel и Redis Cluster.Основные операции Redis можно сослаться на его официальный документ. FЕсли вы заинтересованы в других типах кеша, вы можете найти материалы для самостоятельного изучения.

2. Введение в Redis Sentinel и Redis Cluster

Режим Redis Master-Slave выглядит следующим образом:

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

Из рисунка выше видно, что Sentinel фактически является мостом между Клиентом и Redis. Все клиенты получают услугу Redis Master через программу Sentinel. Прежде всего, Sentinel развертывается в кластере, и полученные Клиентом результаты могут быть связаны с любой службой Sentinel. Во-вторых, все службы Sentinel будут контролировать службу Redis Master-Slave.Если служба мониторинга не отвечает, Sentinel проводит внутренний арбитраж и выбирает slave из всех slave-устройств. И расценивайте других рабов как рабов нового Мастера. Наконец, сообщите всем клиентам о новом главном сервисном адресе. Если старый адрес главной службы будет перезапущен, на этот раз он будет установлен в качестве ведомой службы.

Sentinel может управлять узлами master-slave, и кажется, что стабильность Redis лучше гарантирована. Но если Sentinel является одним узлом, если Sentinel не работает, то модель «ведущий-ведомый» не может играть свою роль. К счастью, Sentinel также поддерживает кластерный режим.Кластерный режим Sentinel в основном имеет следующие преимущества:

Режим кластера Redis Sentinel может повысить стабильность и надежность всего кластера Redis, но когда главный узел узла зависает для повторного выбора нового главного узла, сложность выбора режима кластера Redis Sentinel, очевидно, выше, чем в одной точке. Режим Redis Sentinel требует более надежного алгоритма выбора. Давайте представим «арбитражное совещание» режима кластера Redis Sentinel (несколько Redis Sentinel обсуждают вместе, кто является главным узлом Redis)

1.1, «Арбитражное совещание» режима кластера Redis Sentinel

Когда ведущий контролируется сторожевым кластером, вам необходимо указать для него параметр. Этот параметр указывает количество сторожей, которое требуется, когда мастер должен быть признан недоступным и выполняется аварийное переключение. В этой статье мы временно называем этот параметр количеством голосов, но Когда переключение между основным и подчиненным компонентами переключения при сбое фактически инициируется, восстановление после сбоя не будет происходить немедленно, и большая часть сторожевого устройства в сторожевом устройстве будет авторизована перед выполнением переключения при сбое. Когда ODOWN, происходит переключение при сбое. После запуска аварийного переключения при попытке выполнить аварийное переключение дозорный получит разрешение «большинства» дозорного (если больше голосов, чем у большинства, попросите большее количество дозорного). Эта разница выглядит неуловимой, но легко Понять и использовать. Например, в кластере 5 часовых, а количество голосов установлено равным 2. Когда два стража считают, что мастер недоступен, сработает аварийное переключение, однако часовой, который выполняет аварийное переключение, должен сначала получить авторизацию как минимум от трех часовых. Отказоустойчивость может быть реализована. Если для количества голосов установлено значение 5, для достижения состояния ODOWN все 5 часовых должны быть субъективно признаны главными как недоступные, а для восстановления после сбоя все 5 часовых должны быть авторизованы.

Предыдущие отношения между узлами Redis Cluster показаны ниже:

3. Практика Redis Sentinel и Redis Cluster

Для использования Redis Sentinel и Redis Cluster необходимо представить следующие пакеты jar

1. Использование Redis Sentinel

2. Использование Redis Cluster

Выше описан процесс инициализации и простое использование Redis Sentinel и Redis Cluster. Для других более сложных приложений, пожалуйста, обратитесь к официальному API Redis

В-четвертых, стратегия истечения Redis

1. Регулярно удаляйте

2. Ленивое удаление

3. Регулярно удаляйте

Memcached использует только отложенное удаление, а redis использует как отложенное, так и периодическое удаление, что также является разницей между ними (это можно рассматривать как точку, в которой redis лучше, чем memcached);

Пять, ямы, на которые наступили во время использования Redis

1. В производственной среде необходимо настроить maxIdle, maxTotal, minIdle в GenericObjectPoolConfig. Поскольку значение по умолчанию слишком мало, если трафик в производственной среде относительно велик, будет возникать ситуация, ожидающая подключения с повторным подключением.

2. При использовании Redis Sentinel необходимо в конце выполнить метод jedis.close, чтобы освободить ресурсы.Этот метод close означает, что нормальное соединение возвращается в пул соединений и закрывается ненормальное соединение. В предыдущих версиях jedis для освобождения ресурсов вызывался метод returnResource. Если соединение не нормальное, оно будет использовано повторно. В это время произойдет очень странное исключение. Поэтому рекомендуется использовать более высокую версию джедаев

3. Чтобы лучше использовать пул соединений Redis, рекомендуется использовать JedisPoolConfig вместо GenericObjectPoolConfig. В JedisPoolConfig есть несколько параметров по умолчанию

Источник

Redis: репликация, часть 1 – обзор. Replication vs Sharding. Sentinel vs Cluster. Топология Redis.

Изначально планировался один небольшой пост с примером создания Redis-репликации, но по мере углубления в детали – захотелось описать всё больше и больше, а потому разбил материал на две части.

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

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

Во второй – примеры создания и настройки Master-Slave репликации и использования Redis Sentinel.

В третьей – работа с Redis Sentinel из Python.

В четвёртой – написание Ansible роли для автоматизации развёртывания репликации и Sentinel.

Redis Replication vs Sharding

Redis поддерживает два типа распределения данных – replication (mirroring, дублирование данных) и sharding (partitioning, сегментирование). При этом в кластере (см. ниже) возможно использование обоих типов одновременно.

Replication

Представляет собой копирование всех данных между всеми узлами кластера, что позволяет выполнять запросы к данным с двух или более нод, плюс данные хранятся на всех нодах, таким образом обеспечивая надёжность данных (high availability).

При таком подходе увеличивается скорость выполнения read-операций.

Sharding

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

При таком подходе увеличивается скорость выполнения write-операций.

Redis Sentinel vs Redis Cluster

Redis Sentinel

Был добавлен в Redis v.2.4, и является сервисом мониторинга состояния мастер и слейв нод. Умеет отправлять уведомления о событиях, выполнять переключение между мастером и слейвом, если мастер вышел из строя и т.д. Имеет смысл в использовании, если используется “голая” мастер-слейв репликация без полноценного кластера.

Выполняет настройку нод в случае выхода из строя мастера: определяет, какая из нод станет новым мастером, выполняет их перенастройку на ходу.

Требует как минимум трёх работающих инстансов для достижения кворума при определении статуса Redis-мастера или слейв-нод.

Redis Cluster

Был добавлен в Redis v.3.0, и является полноценным native решением для создания и управления кластером с сегментацией и репликаций данных. Выполняет задачи управления нодами, репликации, синхронизации данных, обеспечением доступа к ним в случае выхода из строя одного или более мастеров.

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

Топология Redis

Один Redis-инстанс

Самый классический случай.

Простой в запуске и настройке.

Ограничен ресурсами хоста, на котором запущен – его процессором и памятью.

В случае выхода из строя хоста или самого сервера Redis – разумеется, упадут все зависящие от него службы, т.е. никакого обеспечения надёжности нет.

Master-slave репликация

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

Данные обновляются на мастере, после чего он отправляет информацию об обновлениях на слейвы.

Слейвы общаются только с мастером (но могут иметь собственные слейвы).

Слейвы являются read-only нодами – никаких изменений на них не выполняется (если явно не задано другое, см. во второй части).

В случае выхода из строя одной из нод – все данные останутся доступными с других улов.

Прост в настройке, но операции записи ограничены доступными мастеру ресурсами.

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

Redis Sentinel

Уже описывался выше, но ещё несколько слов.

Как и в случае с репликацицей Redis – имеет одну Master Sentinel ноду, которая имеет приоритет при принятии решения о том, какую ноду Redis использовать в роли Master.

Т.е, в случае с одним Мастером Redis и двумя слейвами, и если Master Sentinel работает на том же хосте, где Мастер Redis-а, и этот хост умирает – Sentinel определяет свой новый мастер-инстанс, затем два оставшихся Sentinel-инстанса принимают решение о том, какой из оставшихся двух Redis-нод станет новым мастером. При этом у мастер-инстанса Sentinel будет приоритет при принятии решения.

Стоит учитывать, что не все клиенты умеют работать с моделью Redis Sentinel, список клиентов – тут>>>.

Redis Cluster

И самый полнофункциональный вариант – Redis Cluster.

Несколько мастер-инстансов, у каждого один или более слейвов (до 1000).

Выполняет все задачи по шардингу, репликации, failover, синхронизации данных.

Требует как минимум 6 нод Reedis-а: три для мастеров, и три для слейвов.

Умеет перенаправлять запросы от клиентов на нужный мастер или слейв – но это требует поддержки кластера самими клиентами Redis.

Источник

Русские Блоги

Использование Redis Sentinel

Redis Sentinel

Справочник статей

Основная концепция

1.1 Предпосылки: проблема репликации мастер-подчиненный

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

В репликации «главный-подчиненный» существуют следующие проблемы:

Проблема (1) является проблемой высокой доступности Redis и может быть решена с помощью Redis Sentinel, задачи (2) и (3) распределенные проблемы Redis могут быть решены с помощью кластера Redis.

1.2 Высокая доступность Redis Sentinel

Redis Sentinel имеет следующие особенности:

2. Развертывание Redis Sentinel

Далее Redis Sentinel состоит из 3 узлов Sentinel, 1 главного узла и 2 подчиненных узлов, и используется простое шифрование. Топология показана на следующем рисунке.

2.1 Развертывание главного и подчиненного узлов Redis

Начать мастер

Начать раб

Конфигурация двух подчиненных узлов точно такая же, а конфигурация главного узла отличается от конфигурации подчиненного.

Подтвердите отношения мастер-раб

Подключитесь к главному узлу для просмотра:

Диаграмма топологии в это время выглядит следующим образом:

2.2 Развертывание узлов Sentinel

Метод развертывания 3 узлов Sentinel одинаков (разные порты).

2.3 Описание элемента конфигурации Sentinel

（1）sentinel monitor

Конфигурация выглядит следующим образом: sentinel monitor

（2）sentinel down-after-milliseconds

Конфигурация выглядит следующим образом: sentinel down-after-milliseconds

（3）sentinel parallel-syncs

Конфигурация выглядит следующим образом: sentinel parallel-syncs

（4）sentinel failover-timeout

（5）sentinel auth-pass

Конфигурация выглядит следующим образом: sentinel auth-pass

（6）sentinel notification-script

Конфигурация выглядит следующим образом: sentinel notification-script

Интеллектуальная рекомендация

URL-тур

URL-тур Во всем процессе он может быть примерно разделен на следующие процессы. DNS-анализ домена TCP соединение HTTP-запрос Запрос процессов Возвращает ответ HTTP Рендеринг страницы Выключить соедине.

Руководство по обзору кода на основе GitLab

Luo Valley P3809 (вопросы массива суффикса)

phpMyAdmin сообщает об ошибках на главной странице

[Феномен]: phpMyAdmin сообщает о фатальной ошибке: необученная ошибка: вызов неопределенной функции mb_detect_encoding () [Анализ причины]: На этой домашней странице следует подумать, открыты ли библи.

Что такое алгоритм фильтра Блума?

Нажмите вышеСинее словоУстановить звезду Начнем сегодняшнее исследование

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Redis Sentinel

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

Содержание

Highly Available Redis

Redis Sentinel является официальной рекомендацией для запуска высокодоступной конфигурации [Источник 2] Redis, запустив несколько дополнительных обработок Redis Sentinel, чтобы активно отслеживать существующие экземпляры redis master и slave. То есть Redis поддерживает репликацию типа master-slave. Данные с любого сервера Redis могут реплицироваться произвольное количество раз. Репликация полезна для масштабирования чтения (но не записи) или при очень больших объёмах данных. Все данные, которые попадают на один узел Redis (который называется master), будут попадать также на другие узлы (называются slave).

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

Система репликации Redis ещё не поддерживает автоматическую отказоустойчивость. Если master-узел выходит из строя, необходимо вручную выбрать новый master из списка slave-узлов.

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

Как это устроено

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

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

Как это работает

Если класс Sentinel обнаруживает, что master не отвечает, то он выдаст сообщение SDOWN (субъект не работает). А если master остановлен, то сообщение будет таким: ODOWN (объект не работает), и затем будет выбран новый master. Классы Sentinels восстанавливают систему после сбоя, перезаписывая файлы конфигурации запущенных экземпляров Redis.

Приведем пример: у нас есть master «А», содержащий slave «В» и slave «С», также у нас есть три класса Sentinels (s1, s2, s3), работающие на наших серверах приложений, которые работают с Redis. На данный момент «А», наш текущий master, отключается и Sentinel это обнаруживает в автономном режиме и отправляет сообщения SDOWN. Затем получает состояние ODOWN. Далее выбирается новый master. Пусть в этом случае «В» выбирается как новый master. Файл конфигурации для «B» устанавливается так, что он больше не является подчиненным, а файл конфигурации для «C» переписан так, что он больше не является подчиненным «A», а подчиняется «B». Здесь все продолжается как обычно. Если «А» будет доступным, классы Sentinels это обнаружат и перепишут файл конфигурации для «A» как подчиненного для «B», поскольку «B» является текущим master. И так далее.

Примеры архитектуры

Пример 1: Базовая конфигурация

Пример 2: Один Redis и один master

Случай, когда у нас есть только два экземпляра Redis, одна для master и одна для slave. Конфигурация в примере 1 в этом случае небезопасна, поэтому мы идем туда, где Sentinels размещаются там, где находятся клиенты:

Если поле, в котором выполняются M1 и S1, не работает, восстановление после сбоя произойдет без проблем, однако легко видеть, что разные сетевые разделы приводят к различным действиям. Например, Sentinel не сможет настроить, будет ли отключена сеть между клиентами и серверами Redis, так как master Redis и slave будут недоступны.

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

Таким образом, это правильная настройка, но настройка в примере 1 имеет такие преимущества, как система Reda Redis, работающая в тех же самых блоках, что и сам Redis, который может быть проще в управлении.

Особенности Redis Sentinel

Redis Sentinel предоставляет вспомогательные задачи, такие как мониторинг, уведомления и действия в качестве поставщика конфигурации для клиентов. Возможности Sentinel на макроскопическом уровне:

Источник

Горизонтальное масштабирование и отказоустойчивость Redis для сервисных служб DirectumRX

Redis – это система управления базами данных класса NoSQL (не реляционные СУБД), размещаемых целиком в оперативной памяти. Для доступа к данным используется модель «ключ» — «значение». Такая СУБД используется зачастую для хранения кэшей в масштабируемых сервисах, для хранения изображений и данных небольшого размера.

Широкое распространение СУБД Redis получила за счет:

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

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

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

На официальном сайте Redis выделяется 2 способа обеспечения горизонтального масштабирования и отказоустойчивости:

Настройка Redis Sentiel

Вариант с использованием Redis Sentiel (Следящий узел Redis) был реализован в версии Redis 2.4 и состоит в том, что для мониторинга доступности мастера используется дополнительный сервис Redis Sentiel. Он же выполняет настройку узлов реплик, в случае выхода из строя мастера. Определяет какой из SLAVE узлов станет MASTER и выполнит перенастройку на ходу.

Реализует классическую схему:

SLAVE-узлов может быть множество (до 1000 по данным с официального сайта), для продуктивной работы рекомендуется использовать не менее двух SLAVE-узлов.

Обычно схема настраивается таким образом, что на MASTER- и на SLAVE-узлах настраивается сервис Redis Sentiel, и при выходе из строя MASTER-узла, оставшиеся следящие узлы принимают решение о введении в работу нового MASTER.

Актуальная версия Redis доступна для скачивания с официального сайта разработчика продукта. Однако на сайте доступен дистрибутив только для ОС Linux. В своё время, развивался проект Microsoft по портированию Redis на ОС Windows, однако в настоящее время проект остановил развитие на версии 3.2.100, поэтому в данной статье будем рассматривать наиболее актуальный вариант разворачивания – на ОС Linux.

В качестве тестовых узлов будем использовать два виртуальных хоста redis1 и redis2 с установленным дистрибутивом Linux Debian 10.

Первым делом актуализируем списки пакетов из репозитория по умолчанию и устанавливаем Redis:

Пусть redis1 будет выступать в качестве MASTER-узла, а redis2 – в качестве SLAVE-узла.

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

Для redis1 в конфигурационном файле /etc/redis/redis.conf указываем:

Для redis2 в конфигурационном файле /etc/redis/redis.conf указываем:

Выполним перезапуск сервисов redis-server на обоих узлах:

Проверяем на стороне MASTER, что узлы стали репликами и получили необходимые роли:

На стороне SLAVE видим такую же ситуацию:

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

Исходя из документации, следящий сервис Redis Sentinel умеет выполнять следующие операции:

Подключаем аналогичным способом репозиторий Redis и устанавливаем пакет redis-sentinel:

После установки необходимо внести настройки в конфигурационный файл следящего узла /etc/redis/sentinel.conf:

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

Проверим, что следящий сервис увидел MASTER и SLAVE:

Сымитируем сбой, остановим сервис redis-server на узле redis1 и получим текущую информацию следящего узла:

Видим, MASTER поменялся.

Восстановим работу узла redis1 и проверим его состояние:

Видим, что узел получил роль SLAVE, а узел redis2 является MASTER-узлом.

Сымитируем сбой узла redis2 и проверим состояние следящего узла:

И состояние узла redis1:

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

Проксирование обращения к узлам Redis

В качестве reverse-прокси для узлов Redis может выступать любой проксирующий tcp-сервис. В данной статье рассмотрим использование HAProxy, поскольку это специализированный инструмент, предназначенный для обеспечения высокой доступности и балансировки нагрузки, и используется повсеместно известными онлайн сервисами. Подробнее о HAProxy можно почитать на странице разработчика.

Установим HAProxy на узел redis3:

В конфигурационный файл HAProxy /etc/haproxy/haproxy.cfg, добавим настройки для проксирования запросов к узлам Redis:

В данной конфигурации указано, что проксировать будем любые запросы, приходящие на все интерфейсы текущей виртуальной машины по адресу на порт 6379. Запросы будем передавать на узел, который ответит, что он имеет роль MASTER.

Перезапустим сервис haproxy:

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

Остановим узел redis1 и запросим снова список ключей:

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

Теперь достаточно прописать в конфигурационных файлах сервисов DirectumRX адрес reverse-прокси для подключения к Redis.

Настройка Redis Cluster

Вариант кластеризации Redis Cluster реализован для версии redis 3.0 и выше, является решением для создания и управления кластером с сегментацией и репликацией данных. Выполняет задачи управления узлами, репликации, синхронизации данных на узлах и обеспечения доступа клиентского приложения к MASTER-узлу в случае выхода из строя одного из нескольких MASTER-узлов.

Redis Cluster работает в режиме мультимастера, у каждого MASTER-узла может быть один или более SLAVE-узлов (до 1000).

Масштабирование является основной из функций кластера. Помимо этого, кластер может гарантировать отказоустойчивость сервиса Redis:

Также может возникнуть ситуация, когда М1, М3 перестают «видеть» М2, а клиент всё еще продолжает записывать данные в М2. Если недоступность будет продолжаться довольно долго (параметр cluster-node-timeout), то в этом случае S2 будет переведен в режим MASTER, а M2 самостоятельно перестанет работать.

Официальная документация рекомендует использовать 6 узлов — по одному экземпляру Redis на узле, что позволяет обеспечить большую надежность, но никто не запрещает использовать три узла со следующей топологией соединения:

В случае выхода из строя одного из физических узлов соответствующие SLAVE-реплики перейдут в режим MASTER, и работа не будет нарушена.

На тестовом стенде реализуем 3 виртуальных машины (redis1, redis2 и redis3), на каждой из которых будет запущено по 2 экземпляра Redis.

Клиентское приложение будет выполнять подключение к конкретному порту, прописанному в конфигурационном файле клиента, поэтому пары MASTER – SLAVE должны работать на одних и тех же портах.

Для пары M1 – S1 будем использовать порт 6381
Для пары M2 – S2 будем использовать порт 6382
Для пары M3 – S3 будем использовать порт 6383

Подготовим конфигурационные файлы

Заполним конфигурационные файлы по шаблону:

Выполним запуск Redis-узлов:

Для настройки кластера необходимо использовать клиентскую утилиту redis-cli, передав ей на вход список пар ip:port серверов, которые будут играть роль MASTER и SLAVE:

Кластер корректно построен. Выведем информацию о кластере:

Для проверки конкретной реплики, как и в случае с Redis Sentiel, можно использовать команду INFO replication:

Попробуем создать несколько ключей и проверить, что эти ключи появились на репликах:

Выведем из строя узел redis1 и проверим, как отработает S1:

Видим информацию о сбое M1 и S2 и о том, что S3 перешел в режим MASTER.

Проверяем, где хранятся ключи:

Ключи, которые ранее хранились на узле redis1 теперь доступны на узле redis3.

Восстановим работу узла redis1 и проверим состояние узлов M1 и S2:

Работоспособность M1 и S2 восстановилась, но теперь M1 находится в режиме SLAVE.

И ключи также находятся на узле redis3:

Кластер настроен и восстановление работоспособности Redis протестировано.

Для доступа сервисных служб DirectumRX также потребуется настроить реверс-прокси, как и в случае настройки Redis Sentiel.

Вместо заключения

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

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

Возможно, вам будут полезны ссылки ниже для получения более подробной информации по теме:
Redis cluster tutorial
Redis Sentinel Documentation
HAProxy Configuration Manual.

Источник