Redis Sentinel: последний узел не становится главным

Я пытаюсь настроить автоматическую систему аварийного переключения в кластере Redis с 3 узлами. Я установил redis-sentinel на каждом из этих узлов (точно как этот парень: http://www.symantec.com/connect/blogs/configuring-redis-high-availability). Все нормально, пока у меня два-три узла. Проблема в том, что всякий раз, когда остается только onte-узел, который является подчиненным, он не выбирается в качестве главного автоматически. Кворум установлен на 1, поэтому последний узел обнаруживает отключение ведущего устройства, но не может проголосовать за аварийное переключение, поскольку нет большинства.

Чтобы преодолеть эту (неожиданную) проблему, я написал небольшой сценарий, который запрашивает у других узлов их мастера, и, если они не отвечают, я устанавливаю текущий узел как ведущий. Этот сценарий вызывается в файле redis-sentinel.conf как сценарий уведомления. Однако ... Как только служба redis-sentinel запускается, эта конфигурация "стирается"! Если я посмотрю на файл конфигурации в / etc, строка "sentinel notification-script" исчезла (redis-sentinel перезаписывает свой файл конфигурации, так почему бы и нет), НО конфигурация, которую я написал, больше не доступна:

1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "x.x.x.x"
    5) "port"
    6) "6379"
    7) "runid"
    8) "somerunid"
    9) "flags"
   10) "master"
   11) "pending-commands"
   12) "0"
   13) "last-ping-sent"
   14) "0"
   15) "last-ok-ping-reply"
   16) "395"
   17) "last-ping-reply"
   18) "395"
   19) "down-after-milliseconds"
   20) "30000"
   21) "info-refresh"
   22) "674"
   23) "role-reported"
   24) "master"
   25) "role-reported-time"
   26) "171302"
   27) "config-epoch"
   28) "0"
   29) "num-slaves"
   30) "1"
   31) "num-other-sentinels"
   32) "1"
   33) "quorum"
   34) "1"
   35) "failover-timeout"
   36) "180000"
   37) "parallel-syncs"
   38) "1"

Это результат команды часовых-мастеров. Единственное, что я ранее установил для «down-after-milliseconds» значение 5000, а «failover-timeout» - на 10000 ...

Не знаю, встречал ли кто-нибудь что-нибудь подобное? Что ж, если у кого-то есть хоть какое-то представление о том, что происходит, я был бы рад этому;)


redis redis-sentinel
person P. Bender    schedule 22.12.2014    source источник
comment
Что вы сделали, чтобы преодолеть эту проблему, не могли бы вы сказать мне, что это было бы действительно полезно, я столкнулся с той же проблемой и ничего не получил?   -  person Sudhanshu Gaur    schedule 28.03.2016

Ответы (2)


arrow_upward
3
arrow_downward

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

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

Как сказал антирез, для выборов нужно иметь достаточно стражей. Есть два выбора: 1: выбор нового хозяина и 2: выбор дозорного, который будет проводить продвижение по службе. В вашем сценарии у вас есть только один дозорный, но чтобы выбрать дозорного, который будет обрабатывать продвижение по службе, вашему дозорному понадобятся голоса кворума Стражей. Это число составляет большинство всех наблюдаемых часовых. В вашем случае для голосования необходимы два часовых, прежде чем выборы могут состояться. Этот номер кворума не настраивается и не зависит от параметра кворума. Это сделано, чтобы уменьшить шансы нескольких мастеров.

Я также настоятельно не рекомендую устанавливать кворум меньше половины + 1 ваших дозорных. Это может привести к операции разделения мозга, когда у вас есть два мастера. Или в вашем случае у вас может быть три. Если вы потеряли связь между вашим мастером и двумя подчиненными, но у клиентов все еще была связь, ваши настройки могут вызвать разделение мозга - когда подчиненный был повышен, и новые соединения разговаривали с этим мастером, в то время как существующие продолжали разговаривать с оригиналом. Таким образом, у вас есть достоверные данные в двух мастерах, которые, вероятно, конфликтуют друг с другом.

Автор этой статьи Symantec считает, что умирает только демон Redis, а не узел. Таким образом, это действительно не установка высокой доступности.

person The Real Bill    schedule 22.12.2014
comment
Я слышу вашу точку зрения и понимаю проблему кворума, равного 1, но как мне обрабатывать динамические IP-адреса? Я хочу, чтобы каждый новый узел мог присоединиться к кластеру, поэтому мне нужен какой-то механизм для автоматического обнаружения мастера (так как теперь я использую сценарий для его поиска). Забыл упомянуть, что хочу развернуть кластеры с помощью Saltstack. - person P. Bender; 23.12.2014
comment
У вас нет кластера, у вас есть настройка репликации. Это важное различие. Вы используете часового, чтобы обнаружить хозяина. Вы подключаетесь к любому из ваших (статических) часовых и запрашиваете у него мастер модуля (мастер и подчиненный redis), к которому вы хотите подключиться. Когда вы добавляете новые модули, используйте те же часовые и новое имя для этого модуля (то, что вы называете кластером). Одна группа часовых может управлять несколькими модулями Redis. - person The Real Bill; 29.12.2014

arrow_upward
2
arrow_downward

кворум используется только для достижения состояния ODOWN, которое запускает аварийное переключение. Для того, чтобы переключение на самом деле произошло, подчиненное устройство должно проголосовать большинством голосов, поэтому ни один узел не может быть избран. Если у вас есть такое требование, и вас не волнует, что только сторона большинства может продолжить работу в вашем кластере (это означает несвязанную потерю данных на стороне меньшинства, если клиенты разделены с меньшинством, где есть мастер), вы можно просто добавить часовых на клиентские машины, таким образом, общее количество часовых будет, например, 5, и даже если два узла Redis не работают, единственного оставшегося узла плюс два часовых, работающих на стороне клиента, будет достаточно, чтобы получить большую часть 3. К сожалению, документация Sentinel не является достаточно полной, чтобы объяснить это. Есть вся информация, чтобы получить правильное представление, но нет примеров для более быстрого чтения / развертывания.

person antirez    schedule 22.12.2014