[Эта статья была написана Стефани Комбоудон]
P ercona XtraDB Cluster ( PXC ) стал популярным вариантом для обеспечения высокой доступности для серверов MySQL. Однако многим людям все еще трудно понять, что произойдет с кластером, когда один или несколько узлов покинут кластер (изящно или неблагодарно). Это то, что мы разъясним в этом посте.
Узлы уходят изящно
Давайте предположим, что у нас есть кластер из 3 узлов, и все узлы имеют одинаковый вес, который используется по умолчанию.
Что произойдет, если Node1 изящно остановлен ( service mysql stop)? При выключении Node1 сообщит другим узлам, что он покидает кластер. Теперь у нас есть кластер с двумя узлами, а остальные участники имеют 2/2 = 100% голосов. Кластер продолжает работать нормально.
Что происходит сейчас, если Node2 изящно остановлен? То же самое, Node3 знает, что Node2 больше не является частью кластера. Тогда Node3 набирает 1/1 = 100% голосов, и кластер с 1 узлом может продолжать работать.
В этих сценариях нет необходимости в голосовании кворума, поскольку оставшиеся узлы всегда знают, что произошло с узлами, покидающими кластер.
Узлы становятся недоступными
Что произойдет в случае сбоя Node1 в том же 3-узловом кластере, где работают все 3 узла?
На этот раз Node2 и Node3 должны выполнить голосование по кворуму, чтобы оценить, безопасно ли продолжать: у них 2/3 голосов, 2/3> 50%, поэтому у оставшихся 2 узлов есть кворум, и они продолжают работать в обычном режиме.
Обратите внимание, что голосование по кворуму не происходит немедленно, когда Node2 и Node3 не могут присоединиться к Node1. Это происходит только после «подозрительного тайм-аута» ( evs.suspect_timeout ), который по умолчанию составляет 5 секунд. Зачем? Это позволяет кластеру быть устойчивым к коротким сетевым сбоям, что может быть весьма полезно при работе кластера по глобальной сети. Компромисс заключается в том, что в случае сбоя узла записи останавливаются во время подозрительного тайм-аута.
Что произойдет, если Node2 также выйдет из строя?
Снова кворум должен быть проведен. На этот раз Node3 имеет только половину голосов: это не> 50% голосов. У Node3 нет кворума, поэтому он прекращает обработку операций чтения и записи.
Если вы посмотрите на wsrep_cluster_status переменную состояния на оставшемся узле, она покажет NON_PRIMARY. Это указывает на то, что узел не является частью первичного компонента .
Почему оставшийся узел прекращает обработку запросов?
Это вопрос, который я часто слышу: в конце концов, MySQL запущен и работает на Node3, так почему он не может выполнить любой запрос? Дело в том, что Node3 не может узнать, что случилось с Node2:
- Это разбилось? В этом случае для оставшегося узла безопасно продолжать выполнение запросов.
- Или существует сетевой раздел между двумя узлами? В этом случае опасно обрабатывать запросы, потому что Node2 может также обрабатывать другие запросы, которые не будут реплицированы из-за разорванной сетевой связи: в результате получатся два расходящихся набора данных. Это ситуация с раздвоенным мозгом, и это серьезная проблема, так как в дальнейшем может быть невозможно объединить два набора данных. Например, если одна и та же строка была изменена в обоих узлах, какая строка имеет правильное значение?
Голосование за кворум проводится не потому, что это весело, а только потому, что оставшиеся узлы должны общаться друг с другом, чтобы посмотреть, смогут ли они безопасно продолжить работу. И помните, что одна из целей Galera — обеспечить непротиворечивость данных, поэтому каждый раз, когда кластер не знает, безопасно ли продолжать работу, он использует консервативный подход и останавливает обработку запросов.
В таком сценарии будет установлено состояние Node3, NON_PRIMARY и необходимо ручное вмешательство для повторной загрузки кластера с этого узла, выполнив:
SET GLOBAL wsrep_provider_options='pc.boostrap=YES';
В стороне вопрос: теперь понятно, почему записи должны быть запрещены в этом сценарии, но как насчет чтения? Разве мы не можем им позволить?
На самом деле это возможно из PXC 5.6.24-25.11 с настройкой wsrep_dirty_reads .
Вывод
Сплит-мозг — один из злейших врагов скопления Galera. Голосование кворума будет происходить каждый раз, когда один или несколько узлов внезапно становятся недоступными и предназначены для защиты целостности данных. Компромисс состоит в том, что это может повредить доступности, потому что в некоторых ситуациях необходимо ручное вмешательство, чтобы проинструктировать оставшиеся узлы, что они могут принять выполнение запросов.