Технология построения защищенных распределенных приложений



Pdf көрінісі
бет20/30
Дата05.02.2024
өлшемі0.74 Mb.
#490871
түріРеферат
1   ...   16   17   18   19   20   21   22   23   ...   30
Хадуп


разделены на серию маленьких; 
 из-за контроля многопоточности на уровне кластера, транзакции, 
совершающие COMMIT, все еще могут быть прерваны на этом этапе. Могут 
быть две транзакции, пишущие в одну и туже запись разных узлах, и только 
одна из них будет успешно завершена. Другая будет прервана на уровне 
кластера (Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)). Это еще 
раз подтверждает, что масштабируемость поддерживается, в основном, для 
большого объема чтения, но не записи; 
 XA транзакции не поддерживаются из-за возможного rollback-а на 
этапе коммита; 


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. Это означает, что узел не является частью основного 
компонента. 


Достарыңызбен бөлісу:
1   ...   16   17   18   19   20   21   22   23   ...   30




©dereksiz.org 2024
әкімшілігінің қараңыз

    Басты бет