Принцип реализации и простая конструкция Redis Sentinel

Зачем использовать часовой

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

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

Функция часового

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

Мониторинг: Sentinel будет постоянно проверять, правильно ли работают ваши главные и подчиненные узлы.
Уведомление: если есть проблема с отслеживаемым экземпляром Redis, Sentinel может уведомить системного администратора или другие программы через API (pub).
Автоматический переход на другой ресурс: Если мастер находится в автономном режиме, Sentinel запустит отработку отказа, подчиненное устройство под мастером будет выбрано в качестве нового мастера, а другие подчиненные устройства начнут репликацию нового мастера. Приложение может обновить новый главный адрес через механизм уведомлений службы Redis.
Поставщик конфигурации: клиент может использовать Sentinel в качестве авторитетного издателя конфигурации для получения последнего главного адреса. Если происходит отработка отказа, кластер Sentinel уведомляет клиента о новом главном адресе и обновляет конфигурацию Redis.

Принцип дозорного

Для достижения высокой доступности Sentinel обычно состоит из кластера, аналогичного ZooKeeper, и состоит как минимум из 3 узлов. В отличие от ZooKeeper, протоколом распределенной согласованности, используемым Sentinel, является протокол RAFT. Дозорный узелСпециальный узел Redis, за исключением того, что он не хранит данные и поддерживает только некоторые команды.

Три запланированных задачи мониторинга

Sentinel осуществляет обнаружение и мониторинг каждого узла с помощью трех задач мониторинга времени.

каждые 10 секунд, каждый дозорный узел отправит информационную команду главному узлу и подчиненному узлу, чтобы получить информацию о соответствующем узле (информацию о подчиненном узле можно получить, выполнив команду репликации информации на главном узле, поэтому дозорный только необходимо настроить информацию о главном узле, чтобы получить информацию обо всех подчиненных узлах).
каждые 2 секунды, каждый дозорный узел отправит оценку узла о состоянии главного узла и свою собственную информацию в канал _sentinel_:hello узла данных Redis. Когда Sentinel подключается к экземпляру Redis, создаются два подключения: одно — командное, а другое — публикационно-подписное. Каждый дозорный также подпишется на канал _sentinel_:hello, который используется для получения сообщений, опубликованных другими дозорными, чтобы понять мнение других дозорных узлов о статусе главного узла (на основе объективного состояния главного узла в автономном режиме) и информация о других дозорных узлах (используйте для обнаружения новых дозорных узлов).
каждую 1 секунду, каждый дозорный узел отправит команду ping главному узлу, подчиненному узлу и другим дозорным узлам для обнаружения пульса, чтобы подтвердить, доступны ли эти узлы.

Субъективный нижестоящий и объективный нижестоящий

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

Третья задача по времени выше отправляет команду ping всем остальным узлам каждую 1 секунду. Если узел превышает время down-after-millseconds * 10. (По умолчанию 30 секунд). Если нет действительного ответа (+PONG, -LOADING или -MASTERDOWN являются действительными ответами), дозорный узел вынесет решение об ошибке для узла, что называется субъективным отключением.

Цель офлайн (odown)

Когда дозорный узел, субъективно отключенный от сети, является главным узлом, дозорный узел отправит дозорный узел is-master-down-by-addr другим дозорным узлам (эта команда также может использоваться для выбора дозорного лидера), чтобы спросить их о главном узле. Когда решение больше или равно кворуму (это настраивается в файле конфигурации дозорного узла, если количество дозорных узлов равно 3, кворум настраивается как 2). Дозорные думают, что главный узел повесил трубку. , то контрольный узел будет объективно отключен от главного узла. (Таким образом, цель в автономном режиме состоит в том, что большинство дозорных думают, что главный узел не работает)

Выборы лидера Sentinel

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

После того, как Sentinel идентифицирует узел, мастер которого объективно находится в автономном режиме, Sentinel сначала проверит, голосовал ли он за другие Sentinels. Эквивалентом этого является последователь.
Если за Стража не проголосовали, то он становится Кандидатом.
Став кандидатом, Страж должен выполнить несколько задач.
1. Обновите состояние отработки отказа, чтобы начать
2. Добавление 1 к текущей эпохе эквивалентно вводу нового термина.В Sentinel эпоха является термином в протоколе Raft.
3. Время ожидания для самого обновления — это текущее время плюс случайный период времени, а случайное время — это случайное количество миллисекунд в пределах 1 с.
4. Отправьте команду is-master-down-by-addr другим узлам, чтобы запросить голосование. Команда принесет свою эпоху.
5. Голосуйте за себя.В Sentinel способ голосования состоит в том, чтобы изменить лидера и Leader_epoch в вашей мастер-структуре на Sentinel и его эпоху, за которую вы голосуете.
Другие Sentinels получат команду is-master-down-by-addr от Candidate. Если текущая эпоха Стража совпадает с эпохой, переданной ему Кандидатом, это означает, что он проголосовал за этого Кандидата. Проголосовав за других Стражей, вы можете стать Последователем только в течение текущей эпохи.
Кандидат будет продолжать подсчет своих голосов до тех пор, пока не обнаружит, что более половины голосов, согласных с ним как Лидером, больше или равно кворуму. Sentinel добавляет кворум в протокол Raft.Может ли такой Sentinel быть избранным лидером, также зависит от настроенного им кворума.
Если в течение избирательного периода Кандидат не наберет более половины голосов, превышающих или равных кворуму, его избрание признается недействительным.
Если в течение эпохи ни один из кандидатов не наберет достаточного количества голосов. Затем вы можете подождать только более чем в 2 раза больше тайм-аута отработки отказа (по умолчанию время ожидания отработки отказа составляет 3 минуты, поэтому здесь 6 минут), Кандидат увеличивает эпоху и снова голосует.
Если кандидат набирает более половины голосов кворума, он становится Лидером.
В отличие от протокола Raft, лидер не отправляет сообщение о том, что он стал лидером, другим Стражам. После того, как другие Sentinels дождутся, пока ведущий выберет ведущего из ведомых, и обнаружат, что новый ведущий работает нормально, он удалит логотип цели старого ведущего в автономном режиме, поэтому нет необходимости входить в процесс аварийного переключения.

В Sentinel тот, кто первым выполнит субъективное задание в автономном режиме, получит инициативу (первый отправит команды для получения суждения других стражей о мастере, а затем первым выполнит задание в автономном режиме). Когда дозорный выполняет задачу в автономном режиме, он немедленно отправляет команду попросить других дозорных проголосовать.Поскольку каждый дозорный может отдать только один голос, дозорный, запрошенный в начале, может получить 2 голоса, а другие дозорные имеют не более 1 голоса. так что в конце концов Лидер - это вообще тот часовой, который первым попросил голоса.

отказоустойчивость

Избранный лидер отвечает за последующую отработку отказа. Это выбор одного из подчиненных узлов в качестве нового главного узла.

Выберите доступный подчиненный узел.
1. Отфильтруйте неработоспособные (субъективно в автономном режиме или в автономном режиме), пинг дозорного узла не был эффективно отвечен в течение 5 секунд, а отключение от главного узла превышает время простоя после миллисекунд * 10.
2. Выберите подчиненный узел с наивысшим приоритетом подчиненного узла в качестве нового главного.
3. Если приоритет тот же, сравнивается смещение репликации ведомого устройства с исходным ведущим, и ведомое устройство с большим смещением выбирается в качестве нового ведущего.
4. Если смещение репликации одинаково, runid подчиненного устройства сравнивается напрямую, и подчиненное устройство с меньшей строкой выбирается в качестве нового главного.
Выполните команду slaveofnoone на выбранном узле, чтобы сделать его новым ведущим.
Отправьте команды оставшимся подчиненным узлам, чтобы сделать их подчиненными узлами нового мастера, а затем скопируйте данные мастера. Sentinel имеет параметр parallel_syncs, который определяет, сколько ведомых устройств будет реплицировать новый мастер одновременно. Поскольку для начальной репликации используется синхронизация моментальных снимков, ведомое устройство в это время будет в недоступном состоянии, поэтому обычно разрешается репликация только одного ведомого устройства за раз.Хотя это может занять немного больше времени, только одно подчиненное устройство будет недоступен в данный момент.
После всех действий по отработке отказов Leader Sentinel отправит сообщение + switch-master и перезагрузит мастер, операция сброса освободит объект SLAVE исходного мастера и прослушает другие объекты Sentinel мастера, а затем создаст новый подчиненный объект.

Простая сборка Redis Sentinel

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

Сначала скопируйте три копии Redis.conf в рабочий каталог. Затем измените конфигурацию главного и подчиненных узлов.

Главный узел: master.conf

# 后台启动
daemonize yes
# 日志文件对应的位置(日志文件需要自己另行创建，位置可以自己改)
logfile /var/log/redis/master.log
# 端口号
port 6379
# 主节点的密码
# 这里为什么也要配置呢，因为发生故障转移后，当前主节点就会变成从节点
# sentinel只会自动重写主从关系，并不会重写masterauth
masterauth 123456
# 当前结点的密码
requirepass 123456

Ведомый узел 1: slave1.conf

# 后台启动
daemonize yes
# 日志文件对应的位置
logfile /var/log/redis/slave1.log
# 端口号
port 6378
# 主节点的密码
masterauth 123456
# 当前结点的密码
requirepass 123456
# 指定主节点的地址和端口
slaveof 127.0.0.1 6379

Ведомый узел 2: slave2.conf

 # 后台启动
daemonize yes
# 日志文件对应的位置
logfile /var/log/redis/slave2.log
# 端口号
port 6377
# 主节点的密码
masterauth 123456
# 当前结点的密码
requirepass 123456
# 指定主节点的地址和端口
slaveof 127.0.0.1 6379

Запустите три узла отдельно:

sudo redis-server master.conf
sudo redis-server slave1.conf
sudo redis-server slave2.conf

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

Replica 127.0.0.1:6378 asks for synchronization
Starting BGSAVE for SYNC with target: disk
9467:M 01 Feb 2020 16:45:29.290 * Background saving started by pid 9510
9510:C 01 Feb 2020 16:45:29.379 * DB saved on disk
9467:M 01 Feb 2020 16:45:29.526 * Background saving terminated with success
9467:M 01 Feb 2020 16:45:29.527 * Synchronization with replica 127.0.0.1:6378 succeeded

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

Запуск конфигурации Sentinel

Сначала скопируйте три копии redis-sentinel.conf в рабочий каталог и соответственно измените следующие конфигурации трех узлов:

Узел 1: sentinel1.conf

# 端口，也是默认端口
port 26379

# 后台启动
daemonize yes

# sentinel监控Redis主节点的配置
# 对应的命令：sentinel monitor <master-name> <ip> <redis-port> <quorum>  
# master-name 指的是主节点的名字，可以自己定义
# ip 指的是主节点的ip地址
# redis-port 指的是主节点的端口
# quorum 这个值既用于主节点的客观下线，又用于sentinel的leader选举，具体可见上面的原理 
sentinel monitor mymaster 127.0.0.1 6379 2

# 主节点响应sentinel的最大时间间隔，超过这个时间，sentinel认为主节点下线，默认30秒  
sentinel down-after-milliseconds mymaster 3000

# 进行故障转移时，设置最多有多少个slave同时复制新的master
# 由于slave在复制时，会处于不可用的状态(要先清空数据，然后再加载主节点的数据)
# 所以设置一次允许一个slave去复制master
sentinel parallel-syncs master 1

# 故障转移的超时时间，默认3分钟。 
# 当前sentinel对一个master节点进行故障转移后，需要等待这个时间后才能
# 再次对这个master节点进行故障转移(此时其它sentinel依然可以对该master进行故障转移)
# 进行故障转移时，配置所有slave复制master的最大时间，如果超时了，就不会按照parallel-syncs规则进行了
# sentinel进行leader选举时，如果没有选出leader，需要等到2倍这个时间才能进行下一次选举
sentinel failover-timeout master 180000

# 主节点如果设置了密码，就在这里配置
sentinel auth-pass mymaster 123456

# log文件的位置
logfile /var/log/redis/sentinel1.log

Для двух других узлов можно изменить порт, здесь я установил 26378 и 26377.
Запустите три дозорных узла, потому что дозорный тоже является узлом redis, поэтому он тоже запускается командой redis-server, но запускается в дозорном режиме.

sudo redis-server sentinel1.conf --sentinel
sudo redis-server sentinel2.conf --sentinel
sudo redis-server sentinel3.conf --sentinel

Взгляните на журнал запуска sentinel:

9791:X 01 Feb 2020 17:10:52.503 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
9791:X 01 Feb 2020 17:10:52.504 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=9791, just started
9791:X 01 Feb 2020 17:10:52.504 # Configuration loaded
9792:X 01 Feb 2020 17:10:52.523 * Increased maximum number of open files to 10032 (it was originally set to 1024).
9792:X 01 Feb 2020 17:10:52.528 * Running mode=sentinel, port=26379.
9792:X 01 Feb 2020 17:10:52.644 # Sentinel ID is 3b9f4dfc0dcf08b0d21478cf58d0227e1ba61564
9792:X 01 Feb 2020 17:10:52.645 # +monitor master mymaster 127.0.0.1 6379 quorum 2
9792:X 01 Feb 2020 17:10:52.647 * +slave slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6379

9792:X 01 Feb 2020 17:10:52.675 * +slave slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379

9792:X 01 Feb 2020 17:11:18.371 * +sentinel sentinel 0bf2c2c19fcb5e0a77a79485ea7f2d8d012a03d8 127.0.0.1 26378 @ mymaster 127.0.0.1 6379

9792:X 01 Feb 2020 17:11:24.982 * +sentinel sentinel 7ea991444528f91b83fb86534dcb7db28e862507 127.0.0.1 26377 @ mymaster 127.0.0.1 6379

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

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

# Generated by CONFIG REWRITE

# sentinel的工作目录
dir "/home/monk-jay/redis/sentinel"

# 保护模式关闭
protected-mode no

# sentinel监控的master节点对应的领导纪元
# 这个就是用于领导选举时投票用的，记录的是当前投票的leader的纪元
# 这个值和当前纪元相同，说明当前节点已经投过票了
sentinel leader-epoch mymaster 5

# master下的两个slave节点信息
sentinel known-replica mymaster 127.0.0.1 6378
sentinel known-replica mymaster 127.0.0.1 6377

# 另外两个sentinel的信息
sentinel known-sentinel mymaster 127.0.0.1 26377 7ea991444528f91b83fb86534dcb7db28e862507
sentinel known-sentinel mymaster 127.0.0.1 26378 0bf2c2c19fcb5e0a77a79485ea7f2d8d012a03d8

# 当前纪元
sentinel current-epoch 5

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

Способ входа в клиент такой же, как и в Redis, с использованием redis-cli. Поскольку существует несколько экземпляров Redis, необходимо указать порт.

sudo redis-cli -p 26379

Просмотр текущей информации о дозорных.

127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1 # 监控master的数量
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
# 监控的master的信息
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

Просмотр информации обо всех контролируемых мастерах

127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "b16c053f53588d72b655e4d91d2d280a591bc5ff"
    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) "960"
   19) "last-ping-reply"
   20) "960"
   21) "down-after-milliseconds"
   22) "30000"
   23) "info-refresh"
   24) "4073"
   25) "role-reported"
   26) "master"
   27) "role-reported-time"
   28) "58473813"
   29) "config-epoch"
   30) "5"
   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"

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

sentinel master <master_name>

Отображает все подчиненные узлы указанного главного узла и их статус.

sentinel slaves <master_name>

Просмотр адреса и порта указанного мастера

127.0.0.1:26379> sentinel get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6379"

отказоустойчивость

Моделирование простоя

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

127.0.0.1:26379> sentinel failover mymaster
OK

Затем взгляните на журнал текущего часового.

9792:X 02 Feb 2020 11:19:23.353 # Executing user requested FAILOVER of 'mymaster'
9792:X 02 Feb 2020 11:19:23.353 # +new-epoch 6
9792:X 02 Feb 2020 11:19:23.353 # +try-failover master mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:23.431 # +vote-for-leader 3b9f4dfc0dcf08b0d21478cf58d0227e1ba61564 6
9792:X 02 Feb 2020 11:19:23.431 # +elected-leader master mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:23.431 # +failover-state-select-slave master mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:23.523 # +selected-slave slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:23.524 * +failover-state-send-slaveof-noone slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:23.617 * +failover-state-wait-promotion slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:24.611 # +promoted-slave slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:24.612 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:24.659 * +slave-reconf-sent slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:25.605 * +slave-reconf-inprog slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:25.606 * +slave-reconf-done slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:25.671 # +failover-end master mymaster 127.0.0.1 6379
9792:X 02 Feb 2020 11:19:25.672 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6378
9792:X 02 Feb 2020 11:19:25.672 * +slave slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6378

9792:X 02 Feb 2020 11:19:25.673 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6378

Выполнен переход на другой ресурс по запросу пользователя «mymaster» и введена новая эпоха.
Поскольку это failover, предложенный sentinel1, он сначала запрашивает голосование (согласно предыдущей теории известно, что sentinel1 будет избран лидером), что также верно.
Чтобы начать отработку отказа, выберите один из подчиненных узлов в качестве нового главного. Поскольку salve1 является узлом с наивысшим приоритетом по адресу 6378, он будет выбран и повышен до нового главного узла, а затем переназначить принадлежность и использовать оставшиеся подчиненные узлы в качестве подчиненных узлов нового мастера, первоначальный мастер также как подчиненный узел нового мастера.
Sentinel выполняет команду switch-master для переключения slave1 на новый master и уведомляет приложение об изменении мастера и других конфигурациях обновления Sentinel.

В этот момент, если вы снова запустите info sentinel, вы обнаружите, что главный узел изменился.

127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6378,slaves=2,sentinels=3

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

# 这个是新的master的地址和端口，说明salve2是在复制这个新master
# 而且可以看到它是被配置重写自动生成的
# Generated by CONFIG REWRITE
replicaof 127.0.0.1 6378

То же самое касается master.conf, потому что теперь он является ведомым узлом нового мастера и также записан в приведенной выше конфигурации.

реальное время простоя

Сначала посмотрите на текущий процесс Redis:

$ ps -ef | grep redis
root      9523     1  0 Feb01 ?        00:00:20 redis-server *:6377
root      9792     1  0 Feb01 ?        00:00:28 redis-server *:26379 [sentinel]
root      9810     1  0 Feb01 ?        00:00:29 redis-server *:26378 [sentinel]
root      9821     1  0 Feb01 ?        00:00:28 redis-server *:26377 [sentinel]
monk-jay  9889  8399  0 Feb01 tty4     00:00:00 redis-cli -p 26379
root     10039     1  0 Feb01 ?        00:00:10 redis-server *:6379
root     10105     1  0 Feb01 ?        00:00:16 redis-server *:6378
monk-jay 10254  8035  0 11:44 tty2     00:00:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn redis

Поскольку порт моего текущего мастера — 6378, я сейчас убью соответствующий процесс.

# 10105是6378端口这个进程对应的pid
sudo kill -9 10105

повторно войтиps -ef | grep redisВы можете видеть, что процесс, соответствующий порту 6378, исчез, имитируя реальный простой.

Давайте посмотрим на журнал дозорного:

9810:X 02 Feb 2020 11:47:08.158 # +sdown master mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:08.231 # +odown master mymaster 127.0.0.1 6378 #quorum 2/2
9810:X 02 Feb 2020 11:47:08.231 # +new-epoch 7
9810:X 02 Feb 2020 11:47:08.231 # +try-failover master mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:08.339 # +vote-for-leader 0bf2c2c19fcb5e0a77a79485ea7f2d8d012a03d8 7
9810:X 02 Feb 2020 11:47:08.367 # 7ea991444528f91b83fb86534dcb7db28e862507 voted for 7ea991444528f91b83fb86534dcb7db28e862507 7
9810:X 02 Feb 2020 11:47:08.421 # 3b9f4dfc0dcf08b0d21478cf58d0227e1ba61564 voted for 0bf2c2c19fcb5e0a77a79485ea7f2d8d012a03d8 7
9810:X 02 Feb 2020 11:47:08.451 # +elected-leader master mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:08.451 # +failover-state-select-slave master mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:08.507 # +selected-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:08.507 * +failover-state-send-slaveof-noone slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:08.563 * +failover-state-wait-promotion slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:09.443 # +promoted-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:09.444 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:09.460 * +slave-reconf-sent slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:10.423 * +slave-reconf-inprog slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:10.424 * +slave-reconf-done slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:10.490 # +failover-end master mymaster 127.0.0.1 6378
9810:X 02 Feb 2020 11:47:10.490 # +switch-master mymaster 127.0.0.1 6378 127.0.0.1 6379
9810:X 02 Feb 2020 11:47:10.491 * +slave slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6379

9810:X 02 Feb 2020 11:47:10.491 * +slave slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379

9810:X 02 Feb 2020 11:47:40.537 # +sdown slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379

Вы можете видеть первую строку, показывающую sdown, что указывает на то, что sentinel1 субъективно отключил текущий мастер. Затем дозорные начинают договариваться о статусе мастера.Существует больше или равно кворумных дозорных, которых мастер повесил трубку, поэтому дозорные объективно отключены от главного. Затем вступила в новую эру. Остальное такое же, как смоделированное время простоя выше.