Вернуть старый мастер после аварийного переключения redis sentinel

У меня есть 3 настройки Redis Sentinel:

 CLIENT (connects to S1)
          |
          ↓
       +----+
       | M1 | us-east-1
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+
us-east-2      us-west-2

M1 - Master
S1 - Sentinel 1
S2 - Sentinel 2
S3 - Sentinel 3
R2 - First slave (R=replica)
R3 - Second slave

После того, как мой мастер умер, дозорный сделал отработку отказа на R2. Я вернул M1 в онлайн (очистил место на диске), и теперь M1 жив и здоров, но является рабом R2. Есть ли автоматический (или полуавтоматический) способ снова сделать M1 главным, а R2 — подчиненным для M1, а мой трафик снова использовать M1 в качестве главного экземпляра Redis?

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

В настоящее время происходит то, что он выбирает R2 в качестве мастера и перенастраивает его так, чтобы он был:

CLIENT (connects to S1)
          |
          ↓
       +----+
       |[R2]| us-east-2
       | S2 |
       +----+
          |
+----+    |    +----+
|[M1]|----+----| R3 |
| S1 |         | S3 |
+----+         +----+
us-east-1      us-west-2

Когда я переключаюсь вручную, он продвигает R3 как ведущий. (что вполне ожидаемо).

Но затем, когда я снова переключаюсь вручную, он продвигает R2, но я ожидаю, что он продвинет M1.

Все последовательные отработки отказа чередуются между R2 и R2 (при этом M1 всегда остается подчиненным для любого из них).

Приоритет моего подчиненного устройства M1 не указан, поэтому это означает, что его значение по умолчанию равно 100. Приоритет моего подчиненного устройства R2 равен 200, а R2 равен 300. Это заставляет меня думать, что он должен вращать все 3 поля, но он вращает только R2 и R3. после первоначального аварийного переключения.

Мне это кажется сторожевым жуком


redis high-availability redis-sentinel
person Valentin V    schedule 05.07.2018    source источник
comment
Вы когда-нибудь находили решение? У меня та же проблема, но я попытался остановить как нового Мастера, так и Ведомого, чтобы принудительно подключить его к исходному мастеру, но затем часовой говорит, что отказоустойчивость-прерывание-неэффективный-ведомый мастер мой мастер. Я подозревал, что это проблема с кворумом, поэтому я пытается убить исходного мастера, чтобы увидеть, не приведет ли убийство другого мастера к обнаружению одного оставшегося подчиненного устройства таким же хорошим, но это сработало. поэтому по какой-то причине первоначальный хозяин больше не считается хорошим рабом. Подозреваю, что у вас может быть такая же ситуация.   -  person Adriaan    schedule 05.01.2019
comment
@ Адриан Я еще не нашел решения этой проблемы, я просто запускаю старую настройку. Всякий раз, когда происходит аварийное переключение, он выбирает нового мастера. У меня есть надежда, что это сработает в Redis 5, но не было возможности попробовать.   -  person Valentin V    schedule 06.01.2019
comment
Я использую Redis 5 в этой настройке, где у меня возникла проблема с тем, что исходный мастер не был избран. Это так странно. Это должна быть проблема с конфигурацией, потому что для Redis или Sentinel на самом деле не должно иметь значения, что конкретный экземпляр Redis изначально был мастером. Мне придется снова проанализировать файлы конфигурации всех экземпляров...   -  person Adriaan    schedule 06.01.2019
comment
Я нашел свою проблему... как я и ожидал, это проблема конфигурации. Я устанавливаю каждый узел с паролем — и я протестировал исходную установку, и ведомые устройства прекрасно реплицировались. Но я никогда не устанавливал masterauth PASSWRD на исходном мастере, поэтому он неправильно реплицировался, когда стал ведомым, поэтому Sentinel (мудро) отказался повысить его до мастера. Я предлагаю вам проверить правильность репликации вашего исходного мастера.   -  person Adriaan    schedule 08.01.2019

Ответы (2)


arrow_upward
3
arrow_downward

Я думаю, что ответ kiddorails правильный, но, скорее всего, у вас есть проблема, аналогичная моей, когда по какой-то причине ваш оригинальный мастер не воспроизводится правильно. Как только я устранил проблему с репликацией, я мог циклически переключаться между мастерами, выдавая SENTINEL FAILOVER mymaster. Первоначально он просто переключался между двумя первоначальными ведомыми устройствами, но теперь, когда мой первоначальный мастер правильно реплицируется, он циклически проходит через все 3. Поэтому я бы рекомендовал проверить репликацию вашего исходного ведущего устройства после отработки отказа. если вы уверены, что он работает, вы также можете остановить другое ведомое устройство, а затем использовать команду SENTINEL FAILOVER mymaster, чтобы принудительно переключиться на исходное ведущее устройство. Если это не удается, вы знаете, что должна быть проблема с репликацией.

person Adriaan    schedule 07.01.2019
comment
Это правильно, по файлам логов я понял, что репликации не было, потому что я пропустил masterauth на master: 9047:S 12 Nov 16:22:30.995 * (Non critical) Master does not understand REPLCONF listening-port: -NOAUTH Authentication required, как только я это исправил, и репликация произошла, отказоустойчивость сработала! - person route; 12.11.2019

arrow_upward
1
arrow_downward

Я не уверен, почему вы хотите сделать это в первую очередь. Redis, переходящий на R2 и использующий at в качестве мастера, теперь должен отлично работать как обычный экземпляр M1. Если это не так, вы на самом деле неправильно используете Sentinel для обеспечения высокой доступности.

Вы можете просто инициировать переход на другой ресурс вручную с помощью SENTINEL failover R2. Он должен переключиться либо на M1, либо на R3.

person kiddorails    schedule 05.07.2018
comment
как видно из моей диаграммы, R2 находится в Огайо, а M1 — в Западной Вирджинии. Я хочу вернуть его, чтобы уменьшить задержку @kiddorails - person Valentin V; 05.07.2018