Обработка сбоев ArangoDB - Кластер против ActiveFailover - PullRequest
0 голосов
/ 31 января 2019

Допустим, у меня есть 3 узла и две возможные конфигурации ArangoDB:

  • ActiveFailover:
    узел 1: агент
    узел 2: лидер
    узел 3: подписчик

или

  • Кластер:
    узел 1: 1 Агент 1 DBserver и 1 Координатор
    узел 2: 1 Агент 1 DBserver и 1 Координатор
    узел 3:1 агент 1 DBserver и 1 координатор

Теперь предположим, что узлы 1 и 2 отключены.Какая конфигурация более устойчива?Будет ли подписчик в конфигурации ActiveFailover доступным, даже если узел 1, на котором запущен агент, вышел из строя?Или конфигурация кластера будет обрабатывать этот случай более изящно, оставляя узел 3 доступным для обработки операций чтения и записи?

1 Ответ

0 голосов
/ 01 февраля 2019

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

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

Теперь давайте сравним две конфигурации для случая одного узла.сбой: конфигурация ActiveFailover продолжит работать, потому что по крайней мере один из двух узлов данных (Лидер и Последователь) выживет, и вместе с третьим, на котором работает только Агент, они могут выбрать лидера и сделать оставшийся в живых узел данных Лидером.,Если происходит сбой узла «единственный агент», выбор лидера все еще работает, поскольку два других узла фактически также запускают агента.Тем не менее, обратите внимание, что в случае сбоя текущего Лидера происходит аварийное переключение, но поскольку репликация является только асинхронной, некоторые зафиксированные данные могут быть потеряны!

Кластер в основном ведет себя так же, за исключением того, что он имеет более симметричныйнастроить.Если какой-либо узел отказывает, два других могут продолжитьПри условии, что все коллекции имеют как минимум replicationFactor 2, аварийное переключение может переместить лидерство для каждого сегмента в выживающий узел.Поскольку репликация является синхронной, никакие зафиксированные данные не теряются.Это преимущество кластера перед настройкой ActiveFailover.Однако обратите внимание, что задержка операций может быть выше из-за синхронной репликации, и, поскольку не все данные сосредоточены на одном узле, производительность некоторых операций может быть хуже, поскольку у нас меньше локальности данных.В любом случае, такого понятия, как бесплатный обед, не существует, в конце концов нужно платить.

...