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

Question

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

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

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 ...

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

Answer 1

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

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

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

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

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

Answer 2

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