37
способности кластера по записи ограничиваются возможностями
самого слабого узла. Если один узел будет замедлен, с ним замедлится и весь
кластер. Если вам необходима стабильная высокая производительность, она
должна быть поддержана вашим аппаратным обеспечением.
3.2.2 Проблема split-brain и использование кворума
Минимальный рекомендованный размер кластера – 3 узла, что связано с
проблемой split-brain.
Рассмотрим подробнее данную проблему. Допустим, в нашей системе
ровно два совершенно одинаковых узла — A и B. Каждый из них хранит копию
данных второго и может независимо обрабатывать запросы извне. Каждый,
обрабатывая запрос, уведомляет
второго об изменениях, чтобы данные
оставались согласованы.
В случае аварии возможно два варианта:
1 Узел A выходит из строя. Система продолжает работать как ни в чем не
бывало — B продолжает обрабатывать запросы. Когда A приведут в чувство, он
первым делом синхронизируется с B и они вдвоем продолжат работать дальше.
Ни доступность, ни согласованность не страдают.
2 Потеряна связь между A и B. При этом каждый из них продолжает
принимать запросы извне, но не может уведомить второго об изменениях. Для
каждого узла все выглядит так, будто второй узел «умер» и он действует в
одиночку. Эту ситуацию часто называют «split-brain» — мозг разделился на два
полушария, каждое из которых считает себя единственным хозяином ситуации.
Если в этот момент на A был обработан запрос на удаление некой записи R, а
на B был обработан запрос на модификацию
той же самой записи, то данные
стали не согласованы. Когда связь между A и B восстановится, при
синхронизации всплывет конфликт — удалить R или оставить
модифицированную версию? Согласованность данных утеряна.
Для решения данной проблемы Percona XtraDB Cluster в конфигурации с
двумя
узлами работает до тех пор, пока не пропадет связь между узлами. В
случае исчезновения связи кластер полностью блокируется.
Теперь посмотрим, как ведет себя кластер из трех узлов. Будем считать,
что все узлы имеют одинаковый вес, что является значением по умолчанию.
Что произойдет, если узел 1 штатно остановлен (выполнена остановка
сервиса MySQL)? При завершении работы узел 1 сообщит, что он покидает
кластер. Теперь у нас есть кластера из двух узлов, на
оставшихся членов
кластера приходится 2/2 = 100% голосов. Кластер продолжает работать
нормально.
Что произойдет, если и узел 2 штатно будет остановлен? Теперь узел 3
знает, что узел 2 больше не является частью кластера. Узел 3 теперь имеет 1/1 =
100% голосов и кластер с одним узлом может продолжать работать.
В этих сценариях нет необходимости в достижении кворума при
голосовании, так как остальные узлы всегда знают,
что произошло с узлами,
покидающими кластер.
38
Теперь рассмотрим другую ситуацию. На том же 3-узловом кластере, где
запущены все 3 узла, если узел 1 аварийно завершит работу.
На этот раз узлы 2 и 3 должны провести голосование, чтобы определить,
имеют ли они кворум и могут ли безопасно продолжить работу. Они имеют 2/3
голосов, 2/3 > 50%, так что оставшиеся 2 узла имеют кворум и продолжают
работать нормально.
Необходимо иметь в виду, что голосование происходит не сразу, когда
узлы 2 и 3 не могут присоединиться к узлу 1. Голосование происходит только
после достижения тайм-аута (равного по умолчанию 5 секундам). Это
позволяет кластеру быть устойчивым к кратковременным
сбоям сети и может
быть весьма полезны при работе кластера через глобальную сеть. Следствием
является то, что в случае сбоя узла операции записи останавливаются на время
тайм-аута.
Что произойдет, если узел 2 также выйдет из строя? Опять же
необходимо провести голосование. На этот раз узел 3 имеет только 1/2 голосов,
что не превышает 50% голосов. Узел 3 не имеет кворума,
поэтому он
прекращает обработку чтения и записи.
Если посмотреть в этом случае на переменную состояния
wsrep_cluster_status
на
оставшемся
узле,
она
покажет
значение
NON_PRIMARY. Это означает, что узел не является частью основного
компонента.
Достарыңызбен бөлісу: