Как база данных в памяти, Redis должен быть высокодоступным, иначе, если сервер выйдет из строя, данные, все еще находящиеся в памяти, будут потеряны. Наш наиболее часто используемый метод обеспечения высокой доступности — это построение кластера, когда главная машина зависает, а подчиненная машина может быть размещена сверху и продолжать предоставлять услуги. Однако кластер Redis не будет автоматически выполнять переключение ведущий-ведомый, то есть, если главный узел зависает в 3 часа ночи, студенты, занимающиеся эксплуатацией и обслуживанием, немедленно встают и меняют подчиненный узел на ведущий. node, как это Операция очень громоздкая и неэффективная. Для этого Redis официально предлагает решение: Redis Sentinel.
Введение
Кластер Redis Sentinel обычно состоит из узлов от 3 до 5. Если отдельные узлы выходят из строя, кластер все еще может нормально работать. Он отвечает за мониторинг работоспособности кластера Redis. Если главный узел умирает, кластер Sentinel проголосует за выбор нового главного узла. Когда исходный главный узел восстановится, он снова присоединится к кластеру Redis в качестве подчиненного узла нового главного узла.
Фундаментальный
Кластер Sentinel обнаруживает главный узел через указанный файл конфигурации, отслеживает его и отправляет команду info для получения информации о подчиненном узле главного узла. Узлы в кластере Sentinel объявляют о своем существовании другим Sentinel, отправляя приветственную информацию (включая собственный IP-адрес, порт и идентификатор Sentinel) на отслеживаемые главные и подчиненные узлы.
Кластеры Sentinel получают приветственные сообщения от других Sentinel, подписываясь на соединения.
Кластер Sentinel проверяет состояние отслеживаемого экземпляра с помощью команды ping, и если он не возвращается в течение указанного времени, экземпляр считается отключенным.
После того, как Sentinel инициирует аварийное переключение ведущий-подчиненный, он не будет продолжен немедленно. Только после авторизации назначенного (кворума) Sentinel главный узел помечается как ODOWN. Именно тогда начинается фактическое голосование за нового мастера.
Принцип Sentinel для выбора нового мастера: сначала определить приоритет и выбрать тот, у которого меньший приоритет; если приоритет тот же, проверить индекс репликации и выбрать тот, у которого больше реплицируемых данных; если индекс репликации также тот же , выберите идентификатор процесса с более низким приоритетом small.
После того, как Sentinel будет авторизован, он получит номер последней версии конфигурации (config-epoch) вышедшего из строя мастера. Когда выполнение отработки отказа завершится, этот номер версии будет использоваться для последней конфигурации и уведомлять другие Sentinels посредством широковещательной рассылки. конфигурация соответствующего мастера.
основное использование
Давайте возьмем Python в качестве примера, чтобы кратко объяснить, как использовать Sentinel на стороне клиента.
from redis.sentinel import Sentinel
if __name__ == '__main__':
sentinel = Sentinel(['localhost', 26379], socket_timeout=0.1)
print(sentinel.discover_master('mymaster'))
print(sentinel.discover_slaves('mymaster'))
master = sentinel.master_for('mymaster', socket_timeout=0.1)
slave = sentinel.slave_for('mymaster', socket_timeout=0.1)
master.set('follow', 'Jackeyzhe2018')
follow = slave.get('follow')
print(follow)
Методы master_for и slave_for будут извлекать соединение из пула соединений для использования.Если адресов подчиненных устройств несколько, будет использоваться метод опроса.
Когда в Redis происходит переключение master-slave, как клиент узнает, что адрес изменился? Давайте найдем ответ в исходном коде redis-py.
Как видите, когда Redis создает новое соединение, он вызывает метод get_master_address для получения адреса главного узла. В методе get_master_address клиент сначала запрашивает адрес главного узла, а затем сравнивает его с адресом в памяти. Если нет, он отключится и снова подключится, используя новый адрес.
Если мастер-узел не зависает, а Sentinel активно выполняет переключение master-slave, redis-py также обрабатывает эту ситуацию. Это перехватывает исключение ReadOnlyError, затем отключается, а последующие инструкции необходимо переподключать. Конечно, если инструкции по изменению нет, то соединение не переключится, но данные не будут уничтожены, так что влияние невелико.
руки вверх
У нас есть общее представление о том, как работает Sentinel и как его использовать.Чтобы углубить наше понимание, давайте построим кластер Sentinel самостоятельно.
Сначала создайте среду кластера Redis, которая нам нужна.
После установки redis скопируйте 3 копии файла конфигурации redis.conf в каталог redis. Они называются redis6379.conf, redis6380.conf и redis6381.conf соответственно.
Измените следующие элементы в файле redis6381.conf.
bind 127.0.0.1
port 6381
logfile "6381.log"
dbfilename "dump-6381.rdb"
Изменить в redis6379.conf
bind 127.0.0.1
port 6379
logfile "6379.log"
dbfilename "dump-6379.rdb"
slaveof 127.0.0.1 6381
См. redis6379.conf для модификации redis6380.conf. После завершения модификации запустите три экземпляра соответственно. Мы создали среду redis master-slave, которую хотим.
Мы подключаемся к главному узлу и видим информацию о его конфигурации master-slave.
Далее настроим кластер Sentinel. Здесь мы также настраиваем три экземпляра. Скопируйте три файла sentinel.conf и назовите их sentinel-26379.conf, sentinel-26380.conf и sentinel-26381.conf.
Отредактируйте следующее в файле sentinel-26379.conf.
port 26379
daemonize yes
logfile "26379.log"
dir /home/xxx/redis/data
sentinel monitor mymaster 127.0.0.1 6381 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
Содержимое sentinel-26380.conf и sentinel-26381.conf аналогично приведенному выше. После настройки мы используем команду redis-sentinel для запуска 3 экземпляров Sentinel.
На этом этапе мы используем команду redis-cli для подключения к экземпляру 26379 и просмотра информации о дозорных устройствах.
Выяснил, что он начал отслеживать наши 3 узла Redis. На данный момент весь наш кластер развернут, давайте проверим его дальше.
Уничтожьте главный узел, проверьте журнал Sentinel, и вы обнаружите, что Sentinel выбрал нового мастера в соответствии с шагами, которые мы упоминали ранее.
На этом этапе давайте посмотрим на дозорную информацию.
На данный момент 6380 стал новым мастером.
Поздравляем, вам больше не нужно вставать рано утром, чтобы переключать экземпляры Redis master-slave.