Углубленный анализ серии Redis (2) — контрольный режим Redis и кластер высокой доступности

Redis задняя часть сервер балансировки нагрузки

предисловие

Redisизрепликация master-slaveрежим, один разглавный узелНевозможно предоставить услугу из-за сбоя, необходимо вручнуюподчиненный узелПовышен доглавный узел, а также уведомитьклиентвозобновитьадрес главного узлаЭтот подход неисправностей в некоторой степени недопустимо.Redis 2.8позже предоставилRedis Sentinel Сторожевой механизмДля решения этой проблемы.

Другие статьи

текст

1. Обзор высокой доступности Redis

существуетWebна сервере,Высокая доступностьозначает, что сервер можетнормальный доступвремя, измеряемоесколькоНормальное обслуживание может быть предоставлено в течение (99.9%,99.99%,99.999%и т.д). существуетRedisуровень,Высокая доступностьимеет более широкое значение, за исключением того, что гарантия предусматриваетнормальное обслуживание(какразделение мастер-раб,Технология быстрого аварийного восстановленияд.), также необходимо учитыватьРасширение емкости данных,Безопасность данныхи Т. Д.

существуетRedisв, осознатьВысокая доступностьТехнология в основном включаетУпорство,копировать,часовойикластер, вот краткое описание того, что они делают и какие проблемы решают:

  • Упорство: Стойкость естьпростейшийМетод высокой доступности. Его основная функция заключается врезервное копирование данных, который хранит данные вжесткий диск, чтобы гарантировать, что данные не будут потеряны из-за выхода из процесса.

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

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

  • кластер: через кластер,Redisрешенооперация записиневозможнобалансировки нагрузкиа такжевместимость складаполучилаОграничение на одну машинупроблема, достигает болееПолныйизРешение высокой доступности.

2. Основные понятия Redis Sentinel

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

Основное описание существительного:

основа существительное логическая структура физическая структура
Узел данных Redis главный узел и подчиненный узел Главный и подчиненный процессы
главный узел Основная база данных Redis Автономный процесс Redis
ведомый узел (ведомый) Ведомая база данных Redis Автономный процесс Redis
Дозорный узел Мониторинг узлов данных Redis Отдельный процесс Sentinel
Коллекция узлов Sentinel Абстрактная композиция из нескольких узлов Sentinel Несколько узловых процессов Sentinel
Redis Sentinel Схема реализации высокой доступности Redis Коллекция узлов Sentinel и процесс узла данных Redis
прикладной клиент Общий термин для одного или нескольких клиентов Один или несколько клиентских процессов или потоков

как показано на рисунке,RedisизРежим репликации master-slaveиSentinel Архитектура высокой доступностиСхема:

3. Проблема репликации Redis master-slave

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

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

репликация master-slaveТакже существуют следующие проблемы:

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

  2. главный узелизспособность писатьполучилаОграничения для одной машины.

  3. главный узелизвместимость складаполучилаОграничения для одной машины.

  4. собственная репликацияНедостатки также будут более заметными в более ранних версиях, например:Redis Разрывы репликацииЗадний,подчиненный узелбудет инициироватьpsync. В это время, еслиСинхронизация не удалась, это будетПолная синхронизация,основная библиотекавоплощать в жизньполная резервная копияВ то же время это может привести к миллисекундному или второму уровнюКатон.

4. Глубокое погружение в Redis Sentinel

4.1 Архитектура Redis Sentinel

4.2 Основные функции Redis Sentinel

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

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

  • монитор

Sentinelбуду продолжать проверятьглавный сервериподчиненный серверПравильно ли он работает.

  • Уведомление

когда под наблюдениемRedisПроблема с сервером,Sentinelпройти черезAPI сценарийВ направленииадминистраторили другойприменениеОтправить уведомление.

  • автоматический переход на другой ресурс

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

  • поставщик конфигурации

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

4.3 Субъективный и объективный офлайн

по умолчанию,каждый SentinelУзел начнется сраз в секундупара частотRedisузел иразноеизSentinelУзел отправляетPINGкоманду и передать узелОтветитьчтобы определить, находится ли узел в сети или нет.

  • Субъективный офлайн

Субъективный офлайнотносится ко всемглавный узелиподчиненный узел. если вdown-after-millisecondsв течение миллисекунд,SentinelНе получилцелевой узел, это определитузелзаСубъективный офлайн.

  • объективно офлайн

объективно офлайнотносятся только кглавный узел. еслиглавный узелпроизошла ошибка,Sentinelузел пройдетsentinel is-master-down-by-addrкоманду другимSentinelУзел запрашивает у узлагосударственный приговор. если больше чем<quorum>Определение количества узловглавный узелнедосягаемый, т.Sentinelузел будет судитьглавный узелзаобъективно офлайн.

4.4 Команды Sentinel связи

SentinelУзел соединенияRedisКогда экземпляр создан,cmdиpub/subдвасоединять.Sentinelпройти черезcmdподключиться кRedisОтправлять команды поpub/subПодключен кRedisдругое на экземпляреSentinelпример.

SentinelиRedis главный узелиподчиненный узелИнтерактивные команды, в основном в том числе:

Заказ роль
PING SentinelВ направленииRedisузел отправляетPINGкоманда для проверки состояния узла
INFO SentinelВ направленииRedisузел отправляетINFOкоманда, получить егоинформация о ведомом узле
PUBLISH SentinelконтролироватьRedisузел__sentinel__:helloэтоchannelвыпусксобственная информацияиглавный узелсвязанная конфигурация
SUBSCRIBE SentinelподписавшисьRedis главный узелиподчиненный узелиз__sentinel__:helloэтоchannnel, чтобы получить другие службы, отслеживающие ту же службуSentinelузел

SentinelиSentinelИнтерактивные команды, в основном в том числе:

Заказ роль
PING SentinelК другимSentinelузел отправляетPINGкоманда для проверки состояния узла
SENTINEL:is-master-down-by-addr и другиеSentinelвести переговорыглавный узелгосударство, еслиглавный узелвSDOWNСтатус, голос автоматически избирает новыйглавный узел

4.5 Как работает Redis Sentinel

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

  • каждыйSentinelотв секундукак только частота, к тому, что он знаетглавный сервер,подчиненный серверИ другиеSentinel примерОтправитьPINGЗаказ.

  1. еслипример(instance)расстояниепоследний раздействительный ответPINGВремя команды превышаетdown-after-millisecondsуказанное значение, то экземпляр будетSentinelотметить какСубъективный офлайн.

  1. еслиглавный серверОтмечен какСубъективный офлайн, то естьмониторэтоглавный сервервсеSentinelузел, сраз в секундучастота подтвержденияглавный сервердействительно вошелСубъективный офлайнгосударство.

  1. еслиглавный серверотмечен какСубъективный офлайн, и имеетдостаточное количествоизSentinel(по крайней мере доконфигурационный файлУказанный номер) указанлимит временисогласен с этим суждением, то этоглавный серверотмечен какобъективно офлайн.

  1. В общем, каждыйSentinelБудет ли каждый10частота один раз в секунду, насколько это известноглавный сервериподчиненный серверОтправитьINFOЗаказ. когдаглавный серверодеялоSentinelотметить какобъективно офлайнчас,SentinelВ направленииавтономный главный сервервсеподчиненный серверОтправитьINFOЧастота команды будет варьироваться от10менять каждую секунду нараз в секунду.

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

  1. когда не хватаетSentinelдать согласиеглавный серверВ автономном режимеглавный серверизОбъективный офлайн-статусбудет удален. когдаглавный серверперенаправитьSentinelизPINGкоманда возвратадействительный ответчас,главный серверизСубъективный офлайн-статусбудет удален.

Примечание: действительныйPINGОтвет может быть:+PONG,-LOADINGили-MASTERDOWN. еслисерверВозвращайте другие ответы, отличные от трех приведенных выше ответов, или вуказанное времянет ответаPINGкоманда, тоSentinelдумаю сервер вернул ответнедействителен(non-valid).

5. Сборка Redis Sentinel

5.1 Инструкции по развертыванию Redis Sentinel

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

  2. SentinelНе могу гарантироватьсильная консистенция.

  3. ОбщийБиблиотека клиентских приложенийСлужба поддержкиSentinel.

  4. Sentinelнужно постоянноконтрольная работаинаблюдать, чтобы обеспечить высокую доступность.

5.2 Файл конфигурации Redis Sentinel

# 哨兵sentinel实例运行的端口，默认26379  
port 26379
# 哨兵sentinel的工作目录
dir ./

# 哨兵sentinel监控的redis主节点的 
## ip：主机ip地址
## port：哨兵端口号
## master-name：可以自己命名的主节点名字（只能由字母A-z、数字0-9 、这三个字符".-_"组成。）
## quorum：当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了  
# sentinel monitor <master-name> <ip> <redis-port> <quorum>  
sentinel monitor mymaster 127.0.0.1 6379 2

# 当在Redis实例中开启了requirepass <foobared>，所有连接Redis实例的客户端都要提供密码。
# sentinel auth-pass <master-name> <password>  
sentinel auth-pass mymaster 123456  

# 指定主节点应答哨兵sentinel的最大时间间隔，超过这个时间，哨兵主观上认为主节点下线，默认30秒  
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000  

# 指定了在发生failover主备切换时，最多可以有多少个slave同时对新的master进行同步。这个数字越小，完成failover所需的时间就越长；反之，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1，来保证每次只有一个slave，处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1  

# 故障转移的超时时间failover-timeout，默认三分钟，可以用在以下这些方面：
## 1. 同一个sentinel对同一个master两次failover之间的间隔时间。  
## 2. 当一个slave从一个错误的master那里同步数据时开始，直到slave被纠正为从正确的master那里同步数据时结束。  
## 3. 当想要取消一个正在进行的failover时所需要的时间。
## 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来同步数据了
# sentinel failover-timeout <master-name> <milliseconds>  
sentinel failover-timeout mymaster 180000

# 当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本。一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
# 对于脚本的运行结果有以下规则：  
## 1. 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10。
## 2. 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。  
## 3. 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
# sentinel notification-script <master-name> <script-path>  
sentinel notification-script mymaster /var/redis/notify.sh

# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

5.3 Планирование узлов для Redis Sentinel

Роль айпи адрес Номер порта
Redis Master 10.206.20.231 16379
Redis Slave1 10.206.20.231 26379
Redis Slave2 10.206.20.231 36379
Redis Sentinel1 10.206.20.231 16380
Redis Sentinel2 10.206.20.231 26380
Redis Sentinel3 10.206.20.231 36380

5.4 Конфигурация Redis Sentinel

5.4.1 Управление конфигурацией Redis-Server

три копииredis.confфайл в/usr/local/redis-sentinelниже каталога. Три файла конфигурации соответствуютmaster,slave1иslave2триRedisузлазапуск конфигурации.

$ sudo cp /usr/local/redis-4.0.11/redis.conf /usr/local/redis-sentinel/redis-16379.conf
$ sudo cp /usr/local/redis-4.0.11/redis.conf /usr/local/redis-sentinel/redis-26379.conf
$ sudo cp /usr/local/redis-4.0.11/redis.conf /usr/local/redis-sentinel/redis-36379.conf

Измените три файла конфигурации следующим образом:

  • Главный узел: redis-16379.conf
daemonize yes
pidfile /var/run/redis-16379.pid
logfile /var/log/redis/redis-16379.log
port 16379
bind 0.0.0.0
timeout 300
databases 16
dbfilename dump-16379.db
dir ./redis-workdir
masterauth 123456
requirepass 123456
  • Ведомый узел 1: redis-26379.conf
daemonize yes
pidfile /var/run/redis-26379.pid
logfile /var/log/redis/redis-26379.log
port 26379
bind 0.0.0.0
timeout 300
databases 16
dbfilename dump-26379.db
dir ./redis-workdir
masterauth 123456
requirepass 123456
slaveof 127.0.0.1 16379
  • Ведомый узел 2: redis-36379.conf
daemonize yes
pidfile /var/run/redis-36379.pid
logfile /var/log/redis/redis-36379.log
port 36379
bind 0.0.0.0
timeout 300
databases 16
dbfilename dump-36379.db
dir ./redis-workdir
masterauth 123456
requirepass 123456
slaveof 127.0.0.1 16379

если ты сделаешьавтоматический переход на другой ресурс, рекомендуется всемredis.confОни установленыmasterauth. так какавтоматический сбойпросто перепишиотношения хозяин-раб,Сейчасslaveof, не будет записано автоматическиmasterauth. еслиRedisЕсли бы не установить пароль, вы можете игнорировать.

5.4.2 Проверка запуска Redis-Server

начинать по порядку16379,26379и36379триRedisУзел, команда запуска и журнал запуска следующие:

RedisКоманда запуска:

$ sudo redis-server /usr/local/redis-sentinel/redis-16379.conf
$ sudo redis-server /usr/local/redis-sentinel/redis-26379.conf
$ sudo redis-server /usr/local/redis-sentinel/redis-36379.conf

ПроверятьRedisПроцесс запуска:

$ ps -ef | grep redis-server
    0  7127     1   0  2:16下午 ??         0:01.84 redis-server 0.0.0.0:16379 
    0  7133     1   0  2:16下午 ??         0:01.73 redis-server 0.0.0.0:26379 
    0  7137     1   0  2:16下午 ??         0:01.70 redis-server 0.0.0.0:36379

ПроверятьRedisЖурнал запуска:

  • узелredis-16379 
$ cat /var/log/redis/redis-16379.log 
7126:C 22 Aug 14:16:38.907 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7126:C 22 Aug 14:16:38.908 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7126, just started
7126:C 22 Aug 14:16:38.908 # Configuration loaded
7127:M 22 Aug 14:16:38.910 * Increased maximum number of open files to 10032 (it was originally set to 256).
7127:M 22 Aug 14:16:38.912 * Running mode=standalone, port=16379.
7127:M 22 Aug 14:16:38.913 # Server initialized
7127:M 22 Aug 14:16:38.913 * Ready to accept connections
7127:M 22 Aug 14:16:48.416 * Slave 127.0.0.1:26379 asks for synchronization
7127:M 22 Aug 14:16:48.416 * Full resync requested by slave 127.0.0.1:26379
7127:M 22 Aug 14:16:48.416 * Starting BGSAVE for SYNC with target: disk
7127:M 22 Aug 14:16:48.416 * Background saving started by pid 7134
7134:C 22 Aug 14:16:48.433 * DB saved on disk
7127:M 22 Aug 14:16:48.487 * Background saving terminated with success
7127:M 22 Aug 14:16:48.494 * Synchronization with slave 127.0.0.1:26379 succeeded
7127:M 22 Aug 14:16:51.848 * Slave 127.0.0.1:36379 asks for synchronization
7127:M 22 Aug 14:16:51.849 * Full resync requested by slave 127.0.0.1:36379
7127:M 22 Aug 14:16:51.849 * Starting BGSAVE for SYNC with target: disk
7127:M 22 Aug 14:16:51.850 * Background saving started by pid 7138
7138:C 22 Aug 14:16:51.862 * DB saved on disk
7127:M 22 Aug 14:16:51.919 * Background saving terminated with success
7127:M 22 Aug 14:16:51.923 * Synchronization with slave 127.0.0.1:36379 succeeded

Следующие две строки журнала указывают на то, чтоredis-16379в видеRedisизглавный узел,redis-26379иredis-36379в видеподчиненный узел,отглавный узелСинхронные данные.

7127:M 22 Aug 14:16:48.416 * Slave 127.0.0.1:26379 asks for synchronization
7127:M 22 Aug 14:16:51.848 * Slave 127.0.0.1:36379 asks for synchronization
  • узелredis-26379 
$ cat /var/log/redis/redis-26379.log 
7132:C 22 Aug 14:16:48.407 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7132:C 22 Aug 14:16:48.408 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7132, just started
7132:C 22 Aug 14:16:48.408 # Configuration loaded
7133:S 22 Aug 14:16:48.410 * Increased maximum number of open files to 10032 (it was originally set to 256).
7133:S 22 Aug 14:16:48.412 * Running mode=standalone, port=26379.
7133:S 22 Aug 14:16:48.413 # Server initialized
7133:S 22 Aug 14:16:48.413 * Ready to accept connections
7133:S 22 Aug 14:16:48.413 * Connecting to MASTER 127.0.0.1:16379
7133:S 22 Aug 14:16:48.413 * MASTER <-> SLAVE sync started
7133:S 22 Aug 14:16:48.414 * Non blocking connect for SYNC fired the event.
7133:S 22 Aug 14:16:48.414 * Master replied to PING, replication can continue...
7133:S 22 Aug 14:16:48.415 * Partial resynchronization not possible (no cached master)
7133:S 22 Aug 14:16:48.417 * Full resync from master: 211d3b4eceaa3af4fe5c77d22adf06e1218e0e7b:0
7133:S 22 Aug 14:16:48.494 * MASTER <-> SLAVE sync: receiving 176 bytes from master
7133:S 22 Aug 14:16:48.495 * MASTER <-> SLAVE sync: Flushing old data
7133:S 22 Aug 14:16:48.496 * MASTER <-> SLAVE sync: Loading DB in memory
7133:S 22 Aug 14:16:48.498 * MASTER <-> SLAVE sync: Finished with success
  • узелredis-36379 
$ cat /var/log/redis/redis-36379.log 
7136:C 22 Aug 14:16:51.839 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7136:C 22 Aug 14:16:51.840 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7136, just started
7136:C 22 Aug 14:16:51.841 # Configuration loaded
7137:S 22 Aug 14:16:51.843 * Increased maximum number of open files to 10032 (it was originally set to 256).
7137:S 22 Aug 14:16:51.845 * Running mode=standalone, port=36379.
7137:S 22 Aug 14:16:51.845 # Server initialized
7137:S 22 Aug 14:16:51.846 * Ready to accept connections
7137:S 22 Aug 14:16:51.846 * Connecting to MASTER 127.0.0.1:16379
7137:S 22 Aug 14:16:51.847 * MASTER <-> SLAVE sync started
7137:S 22 Aug 14:16:51.847 * Non blocking connect for SYNC fired the event.
7137:S 22 Aug 14:16:51.847 * Master replied to PING, replication can continue...
7137:S 22 Aug 14:16:51.848 * Partial resynchronization not possible (no cached master)
7137:S 22 Aug 14:16:51.850 * Full resync from master: 211d3b4eceaa3af4fe5c77d22adf06e1218e0e7b:14
7137:S 22 Aug 14:16:51.923 * MASTER <-> SLAVE sync: receiving 176 bytes from master
7137:S 22 Aug 14:16:51.923 * MASTER <-> SLAVE sync: Flushing old data
7137:S 22 Aug 14:16:51.924 * MASTER <-> SLAVE sync: Loading DB in memory
7137:S 22 Aug 14:16:51.927 * MASTER <-> SLAVE sync: Finished with success

5.4.3 Управление конфигурацией Sentinel

три копииredis-sentinel.confфайл в/usr/local/redis-sentinelниже каталога. Три файла конфигурации соответствуютmaster,slave1иslave2триRedisузлаКонфигурация часового.

$ sudo cp /usr/local/redis-4.0.11/sentinel.conf /usr/local/redis-sentinel/sentinel-16380.conf
$ sudo cp /usr/local/redis-4.0.11/sentinel.conf /usr/local/redis-sentinel/sentinel-26380.conf
$ sudo cp /usr/local/redis-4.0.11/sentinel.conf /usr/local/redis-sentinel/sentinel-36380.conf
  • Узел 1: sentinel-16380.conf
protected-mode no
bind 0.0.0.0
port 16380
daemonize yes
sentinel monitor master 127.0.0.1 16379 2
sentinel down-after-milliseconds master 5000
sentinel failover-timeout master 180000
sentinel parallel-syncs master 1
sentinel auth-pass master 123456
logfile /var/log/redis/sentinel-16380.log
  • Узел 2: sentinel-26380.conf
protected-mode no
bind 0.0.0.0
port 26380
daemonize yes
sentinel monitor master 127.0.0.1 16379 2
sentinel down-after-milliseconds master 5000
sentinel failover-timeout master 180000
sentinel parallel-syncs master 1
sentinel auth-pass master 123456
logfile /var/log/redis/sentinel-26380.log
  • Узел 3: sentinel-36380.conf
protected-mode no
bind 0.0.0.0
port 36380
daemonize yes
sentinel monitor master 127.0.0.1 16379 2
sentinel down-after-milliseconds master 5000
sentinel failover-timeout master 180000
sentinel parallel-syncs master 1
sentinel auth-pass master 123456
logfile /var/log/redis/sentinel-36380.log

5.4.4 Проверка запуска Sentinel

начинать по порядку16380,26380и36380триSentinelУзел, команда запуска и журнал запуска следующие:

$ sudo redis-sentinel /usr/local/redis-sentinel/sentinel-16380.conf
$ sudo redis-sentinel /usr/local/redis-sentinel/sentinel-26380.conf
$ sudo redis-sentinel /usr/local/redis-sentinel/sentinel-36380.conf

ПроверятьSentinelПроцесс запуска:

$ ps -ef | grep redis-sentinel
    0  7954     1   0  3:30下午 ??         0:00.05 redis-sentinel 0.0.0.0:16380 [sentinel] 
    0  7957     1   0  3:30下午 ??         0:00.05 redis-sentinel 0.0.0.0:26380 [sentinel] 
    0  7960     1   0  3:30下午 ??         0:00.04 redis-sentinel 0.0.0.0:36380 [sentinel]

ПроверятьSentinelЖурнал запуска:

  • узелsentinel-16380 
$ cat /var/log/redis/sentinel-16380.log 
7953:X 22 Aug 15:30:27.245 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7953:X 22 Aug 15:30:27.245 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7953, just started
7953:X 22 Aug 15:30:27.245 # Configuration loaded
7954:X 22 Aug 15:30:27.247 * Increased maximum number of open files to 10032 (it was originally set to 256).
7954:X 22 Aug 15:30:27.249 * Running mode=sentinel, port=16380.
7954:X 22 Aug 15:30:27.250 # Sentinel ID is 69d05b86a82102a8919231fd3c2d1f21ce86e000
7954:X 22 Aug 15:30:27.250 # +monitor master master 127.0.0.1 16379 quorum 2
7954:X 22 Aug 15:30:32.286 # +sdown sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379
7954:X 22 Aug 15:30:34.588 # -sdown sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379

sentinel-16380узлаSentinel IDза69d05b86a82102a8919231fd3c2d1f21ce86e000, и пройтиSentinel IDдобавить себяsentinelв кластере.

  • узелsentinel-26380 
$ cat /var/log/redis/sentinel-26380.log 
7956:X 22 Aug 15:30:30.900 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7956:X 22 Aug 15:30:30.901 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7956, just started
7956:X 22 Aug 15:30:30.901 # Configuration loaded
7957:X 22 Aug 15:30:30.904 * Increased maximum number of open files to 10032 (it was originally set to 256).
7957:X 22 Aug 15:30:30.905 * Running mode=sentinel, port=26380.
7957:X 22 Aug 15:30:30.906 # Sentinel ID is 21e30244cda6a3d3f55200bcd904d0877574e506
7957:X 22 Aug 15:30:30.906 # +monitor master master 127.0.0.1 16379 quorum 2
7957:X 22 Aug 15:30:30.907 * +slave slave 127.0.0.1:26379 127.0.0.1 26379 @ master 127.0.0.1 16379
7957:X 22 Aug 15:30:30.911 * +slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 16379
7957:X 22 Aug 15:30:36.311 * +sentinel sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379

sentinel-26380узлаSentinel IDза21e30244cda6a3d3f55200bcd904d0877574e506, и пройтиSentinel IDдобавить себяsentinelв кластере. В настоящее времяsentinelуже в кластереsentinel-16380иsentinel-26380два узла.

  • узелsentinel-36380 
$ cat /var/log/redis/sentinel-36380.log 
7959:X 22 Aug 15:30:34.273 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7959:X 22 Aug 15:30:34.274 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7959, just started
7959:X 22 Aug 15:30:34.274 # Configuration loaded
7960:X 22 Aug 15:30:34.276 * Increased maximum number of open files to 10032 (it was originally set to 256).
7960:X 22 Aug 15:30:34.277 * Running mode=sentinel, port=36380.
7960:X 22 Aug 15:30:34.278 # Sentinel ID is fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7
7960:X 22 Aug 15:30:34.278 # +monitor master master 127.0.0.1 16379 quorum 2
7960:X 22 Aug 15:30:34.279 * +slave slave 127.0.0.1:26379 127.0.0.1 26379 @ master 127.0.0.1 16379
7960:X 22 Aug 15:30:34.283 * +slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 16379
7960:X 22 Aug 15:30:34.993 * +sentinel sentinel 21e30244cda6a3d3f55200bcd904d0877574e506 127.0.0.1 26380 @ master 127.0.0.1 16379

sentinel-36380узлаSentinel IDзаfd166dc66425dc1d9e2670e1f17cb94fe05f5fc7, и пройтиSentinel IDдобавить себяsentinelв кластере. В настоящее времяsentinelуже в кластереsentinel-16380,sentinel-26380иsentinel-36380три узла.

5.4.5 Обновление конфигурации Sentinel

  • Узел 1: sentinel-16380.conf

sentinel-16380.confЗапишите элементы конфигурации нового поколения следующим образом:

# Generated by CONFIG REWRITE
dir "/usr/local/redis-sentinel"
sentinel config-epoch master 0
sentinel leader-epoch master 0
sentinel known-slave master 127.0.0.1 36379
sentinel known-slave master 127.0.0.1 26379
sentinel known-sentinel master 127.0.0.1 26380 21e30244cda6a3d3f55200bcd904d0877574e506
sentinel known-sentinel master 127.0.0.1 36380 fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7
sentinel current-epoch 0

Можно заметить, что,sentinel-16380.confзаподлицо написаноRedisВсе, что связано с главным узломподчиненный узел redis-26379иredis-36379, при написании двух другихSentinelузелsentinel-26380иsentinel-36380изIPадрес,Номер портаиSentinel ID.

# Generated by CONFIG REWRITE
dir "/usr/local/redis-sentinel"
sentinel config-epoch master 0
sentinel leader-epoch master 0
sentinel known-slave master 127.0.0.1 26379
sentinel known-slave master 127.0.0.1 36379
sentinel known-sentinel master 127.0.0.1 36380 fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7
sentinel known-sentinel master 127.0.0.1 16380 69d05b86a82102a8919231fd3c2d1f21ce86e000
sentinel current-epoch 0

Можно заметить, что,sentinel-26380.confзаподлицо написаноRedisВсе, что связано с главным узломподчиненный узел redis-26379иredis-36379, при написании двух другихSentinelузелsentinel-36380иsentinel-16380изIPадрес,Номер портаиSentinel ID.

# Generated by CONFIG REWRITE
dir "/usr/local/redis-sentinel"
sentinel config-epoch master 0
sentinel leader-epoch master 0
sentinel known-slave master 127.0.0.1 36379
sentinel known-slave master 127.0.0.1 26379
sentinel known-sentinel master 127.0.0.1 16380 69d05b86a82102a8919231fd3c2d1f21ce86e000
sentinel known-sentinel master 127.0.0.1 26380 21e30244cda6a3d3f55200bcd904d0877574e506
sentinel current-epoch 0

Можно заметить, что,sentinel-36380.confзаподлицо написаноRedisВсе, что связано с главным узломподчиненный узел redis-26379иredis-36379, при написании двух другихSentinelузелsentinel-16380иsentinel-26380изIPадрес,Номер портаиSentinel ID.

5.5 Команды клиента Sentinel

  • Проверить другоеSentinelсостояние узла, возвратPONGнормально.
> PING sentinel
  • показать все отслеживаемыеглавный узели их статус.
> SENTINEL masters
  • отображаемое обозначениеглавный узелИнформация и статус.
> SENTINEL master <master_name>
  • отображаемое обозначениеглавный узелвсеподчиненный узели их статус.
> SENTINEL slaves <master_name>

вернуть указанныйглавный узелизIPадрес ипорт. если в процессеfailoverилиfailoverЗавершено, будет отображаться Повышено доглавный узелизподчиненный узелизIPадрес ипорт.

> SENTINEL get-master-addr-by-name <master_name>
  • сбросить имя, чтобы оно соответствовало этомурегулярное выражениеиз всехглавный узелинформация о состоянии, очистка предыдущегоинформация о состоянии,а такжеподчиненный узелИнформация.
> SENTINEL reset <pattern>
  • Форма токаSentinelВыполнение узлаfailover, и не нужно получать другиеSentinelсогласие узла. ноfailoverпозжепоследняя конфигурацияотправить другимSentinelузел.
SENTINEL failover <master_name>

6. Аварийное переключение и восстановление Redis Sentinel

6.1 Трассировка клиента Redis CLI

Журнал выше показывает,redis-16379Узелглавный узел, его процессIDза7127. имитироватьRedisМастер-узел выходит из строя, принудительно убивает процесс.

$ kill -9 7127

использоватьredis-cliзапись клиентской командыsentinel-16380узел, видRedis узелинформация о состоянии.

$ redis-cli -p 16380
  • ПроверятьRedisмастер-ведомый кластерглавный узелИнформация. Его можно найтиredis-26379Повышен доновый главный узел.

127.0.0.1:16380> SENTINEL master master
 1) "name"
 2) "master"
 3) "ip"
 4) "127.0.0.1"
 5) "port"
 6) "26379"
 7) "runid"
 8) "b8ca3b468a95d1be5efe1f50c50636cafe48c59f"
 9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "588"
19) "last-ping-reply"
20) "588"
21) "down-after-milliseconds"
22) "5000"
23) "info-refresh"
24) "9913"
25) "role-reported"
26) "master"
27) "role-reported-time"
28) "663171"
29) "config-epoch"
30) "1"
31) "num-slaves"
32) "2"
33) "num-other-sentinels"
34) "2"
35) "quorum"
36) "2"
37) "failover-timeout"
38) "180000"
39) "parallel-syncs"
40) "1"

6.2 Отслеживание журнала Redis Sentinel

Посмотреть любойSentinelЖурнал узла выглядит следующим образом:

7954:X 22 Aug 18:40:22.504 # +tilt #tilt mode entered
7954:X 22 Aug 18:40:32.197 # +tilt #tilt mode entered
7954:X 22 Aug 18:41:02.241 # -tilt #tilt mode exited
7954:X 22 Aug 18:48:24.550 # +sdown master master 127.0.0.1 16379
7954:X 22 Aug 18:48:24.647 # +new-epoch 1
7954:X 22 Aug 18:48:24.651 # +vote-for-leader fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 1
7954:X 22 Aug 18:48:25.678 # +odown master master 127.0.0.1 16379 #quorum 3/2
7954:X 22 Aug 18:48:25.678 # Next failover delay: I will not start a failover before Wed Aug 22 18:54:24 2018
7954:X 22 Aug 18:48:25.709 # +config-update-from sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379
7954:X 22 Aug 18:48:25.710 # +switch-master master 127.0.0.1 16379 127.0.0.1 26379
7954:X 22 Aug 18:48:25.710 * +slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 26379
7954:X 22 Aug 18:48:25.711 * +slave slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379
7954:X 22 Aug 18:48:30.738 # +sdown slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379
7954:X 22 Aug 19:38:23.479 # -sdown slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379
  • Анализируя журналы, вы можете найтиredis-16329Узел входит первымsdown Субъективный офлайнгосударство.
+sdown master master 127.0.0.1 16379
  • Sentinel обнаруженredis-16329произошла ошибка,SentinelВведитеновая эра,от0стать1.
+new-epoch 1
  • триSentinelУзел начинает переговорыглавный узелСостояние, судя по необходимостиобъективно офлайн.
+vote-for-leader fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 1
  • ПревосходитьquorumколичествоSentinelузел думаетглавный узелпроизошла ошибка,redis-16329запись узлаобъективно офлайнгосударство.
+odown master master 127.0.0.1 16379 #quorum 3/2
  • SentinalпровестиАвтоматический переход на другой ресурс, согласованоredis-26329узел как новыйглавный узел.
+switch-master master 127.0.0.1 16379 127.0.0.1 26379
  • redis-36329узел и ужеобъективно офлайнизredis-16329узел становитсяredis-26479изподчиненный узел.
7954:X 22 Aug 18:48:25.710 * +slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 26379
7954:X 22 Aug 18:48:25.711 * +slave slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379

6.3 Файл конфигурации Redis

посмотреть три по отдельностиredisФайл конфигурации узла, происходитглавный-ведомый переключательВремяredis.confОбновление конфигурации происходит автоматически.

  • узел-редис-16379
daemonize yes
pidfile "/var/run/redis-16379.pid"
logfile "/var/log/redis/redis-16379.log"
port 16379
bind 0.0.0.0
timeout 300
databases 16
dbfilename "dump-16379.db"
dir "/usr/local/redis-sentinel/redis-workdir"
masterauth "123456"
requirepass "123456"
  • узел-редис-26379
daemonize yes
pidfile "/var/run/redis-26379.pid"
logfile "/var/log/redis/redis-26379.log"
port 26379
bind 0.0.0.0
timeout 300
databases 16
dbfilename "dump-26379.db"
dir "/usr/local/redis-sentinel/redis-workdir"
masterauth "123456"
requirepass "123456"
  • узел-редис-36379
daemonize yes
pidfile "/var/run/redis-36379.pid"
logfile "/var/log/redis/redis-36379.log"
port 36379
bind 0.0.0.0
timeout 300
databases 16
dbfilename "dump-36379.db"
dir "/usr/local/redis-sentinel/redis-workdir"
masterauth "123456"
requirepass "123456"
slaveof 127.0.0.1 26379

анализировать:redis-26379узелslaveofКонфигурация удалена, повышена доглавный узел.redis-16379узел находится внерабочее состояние.redis-36379изslaveofКонфигурация обновлена ​​до127.0.0.1 redis-26379,статьredis-26379изподчиненный узел.

перезапустить узелredis-16379. После нормального запуска проверьте егоredis.confфайл, настроенный следующим образом:

daemonize yes
pidfile "/var/run/redis-16379.pid"
logfile "/var/log/redis/redis-16379.log"
port 16379
bind 0.0.0.0
timeout 300
databases 16
dbfilename "dump-16379.db"
dir "/usr/local/redis-sentinel/redis-workdir"
masterauth "123456"
requirepass "123456"
# Generated by CONFIG REWRITE
slaveof 127.0.0.1 26379

узелredis-16379добавить новую строку в файл конфигурацииslaveofНастройка свойств, указываяredis-26379, который становитсяновый главный узелизподчиненный узел.

резюме

Эта статья впервыеRedisРазъяснено и указано несколько режимов для достижения высокой доступности.Redis репликация master-slaveнедостатки, дополнительно введенныеRedis Sentinel Режим стражасвязанные понятия, подробно объясненныеRedis Sentinelизконкретная функция,Фундаментальный,Сборка с высокой доступностьюиАвтоматический переход на другой ресурспроверка и т.д.

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

Ссылаться на

«Разработка и эксплуатация Redis»

Никакого общественного внимания к технологиям: Zero One Technology Stack

零壹技术栈

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

Категории