- Все для CMS | Joomla, Drupal, phpBB, Wordpress, DLE, IPB - http://cmsart.ru -

Повышенная доступность MySQL Cluster и алгоритм арбитража

Posted By Archi On 20.08.2012 @ 8:54 дп In MySQL | No Comments

Статья описывает принципы построения отказоустойчивых конфигураций кластера MySQL и алгоритмы, срабатывающие при отказе нод кластера.

Введение

MySQL Cluster — решение для построения отказоустойчивых систем. Во введении кратко опишем базовые понятия, более подробная информация в документации. Описанное ниже справедливо для версии MySQL Cluster 5.1, находящейся в момент выпуска статьи в стадии релиз-кандидата.

Нодой будем называть логический сервер, составляющий кластер. Но одном физическом сервере может быть размещено несколько нод. В кластере три основных типа нод:

1. Дата-нода (ndb-нода) — исполняемый процесс ndbd, отвечающий за хранение фрагмента данных в кластере. Важный параметр кластера NoOfReplicas (число реплик) — число дата-нод на которых хранится каждый конкретный фрагмент. Общее число дата-нод должно быть кратно числу реплик. Группа нод — несколько нод (число нод в группе равно числу реплик), хранящих идентичную информацию. Например NoOfReplicas = 2, число нод — 6. Каждая таблица разбита на 6 фрагментов (по хэшу первичного ключа), пронумеруем их F1,F2,F3,F4,F5,F6. 6 нод (D1,D2,D3,D4,D5,D6) составляют 3 группы — каждая нода первой группы (D1,D2) хранит фрагменты F1,F2; ноды второй группы D3,D4 хранят фрагменты F3,F4; ноды третьей группы D5,D6 хранят фрагменты F5,F6. Выход из строя всех нод одной группы приводит к отказу кластера.
2. SQL-нода (или API-нода) — исполняемый процесс mysqld. SQL-нода принимает подключение клиентов и обращается к дата-нодам за данными. Кроме того, каждая SQL-нода вправе хранить собственные не-NDB таблицы (MyISAM, Innodb, …), как если бы она не входила в кластер.
3. Управляющая нода (management-нода) — исполняемый процесс ndbmgmd. Отвечает за конфигурацию кластера, каждая нода обращается к управляющей ноде при подключению к кластеру. Не управляет транзакциями и другими текущими делами, а концентрируется исключительно на конфигурации. Потребляет немного системных ресурсов, поэтому часто размещается на одном же физическом сервере с другой нодой. В случае выхода из строя управляющей ноды, кластер продолжит нормальную работу, но будет невозможен перезапуск нод. Конфигурация может содержать одну или несколько управляющих нод.

Арбитр и алгортимы арбитража
Арбитр

Одна из нод кластера всегда является арбитром. Арбитр назначается при запуске кластера и может изменяться в рамках процедуры смены арбитра. О назначении и смене арбитра можно узнать в логах кластера. В конфигурации по-умолчанию, арбитром является управляющая нода, однако это не обязательно так. Арбитром может стать любая управляющая или SQL-нода. У этих нод в конфигурации может быть указан параметр ArbitrationRank (ранг арбитра); значения параметра следующие: 0 — нода никогда не станет арбитром, 1 — нода станет арбитром с высоким приоритетом; 2 — нода станет арбитром только если нет претендентов с высоким приритетом. В каждый момент в кластере только один арбитр.
Отключение группы нод, split-brain

Арбитр требуется в ситуации, когда от кластера отключились несколько нод. Пусть кластер физически разделился на 2 кусочка (например, в силу отказа сетевого маршрутиризатора). Возможна ситуация, когда каждый кусочек будет хранить все данные кластера (то есть по крайней мере по одной ноде из каждой группы). Каждый кусочек будет вести себя как полный кластер, что приведет к нарушению целостности данных (например, часть клиентов будет работать с одним кусочком, а часть — с другим). Такая ситуация потенциально опасна и называется split-brain.
Алгоритм арбитража

Алгоритм арбитража достаточно простой. Он начинает работу сразу после обнаружения фрагментации на каждой работающей дата-ноде осколка кластера.

1. Вижу ли я по крайней мере одну дата-ноду из каждой группы (иначе говоря — обладает ли видимая часть кластера всеми данными)? Если нет — выключиться. Если да, продолжить алгоритм
2. Есть ли среди отключившихся дата-нод по одной из ноде из каждой группы (иначе говоря — обладает ли вторая часть всеми данными)? Если нет — значит вторая часть выключится по правилу 1, я могу продолжить работу. Если да, продолжить алгоритм.
3. Спросить арбитра. Если арбитр недоступен — выключиться. Если арбитр доступен, узнать присутствую ли я в текущей конфигурации, если нет — выключиться, если да — продолжить работу

Смена арбитра

Если в результате фрагментации исчез арбитр, то после выполнения алгоритма арбитража, ноды выбирают нового арбитра. Алгоритм выбора в настоящее время простой — выбирается нода с наименьшим номером (nodeid), среди имеющих старший ArbitrationRank.
Примеры
Почему конфигурация из двух физических не является оказоустойчивой?

Рассмотрим следующую конфигурацию, постоенную на двух физических машинах:

* Первый сервер — дата-нода 1, SQL-нода 1, управляющая нода 1
* Второй сервер — дата-нода 2, SQL-нода 2, (возможно также управляющая нода 2)

Значение NoOfReplicas=2 обеспечивает дублирование данных; обе ноды входят в одну группу. На первый взгляд кажется, что конфигурация откзоустойчива, но на практике это не так. При старте кластера арбитром станет первая управляющая нода. Рассмотрим ситуацию, в которой вышел из строя первый сервер (например выключился, сгорела сетевая карта или вышел из строя порт в маршрутиризаторе). На второй дата-ноде сработает алгоритм арбитража:

1. Вижу ли по одной ноде из каждой группы? Да, всего одна группа, эта нода — я.
2. Содержит ли отключивашаяся часть полный набор данных? Да, дата-нода 1 содержит копию данных.
3. Спросить арбитра. Арбитр недоступен. Выключиться.

Мы видим, что отказ одного сервера приводит к отключению всего кластера. То же самое произойдет в конфигурации с тремя серверами и NoOfReplicas=3 при отключении сервера, содержащего арбитра.
Простой пример отказоустойчивой конфигурации

Предоставим читателю убедиться в том, что следующая конфигурация является устойчивой по отношению к отказу любого из трех физических серверов:

* Первый сервер — дата-нода 1, SQL-нода 1 (ArbitrationRank=0), (NoOfReplicas=2)
* Второй сервер — дата-нода 2, SQL-нода 2 (ArbitrationRank=0), (NoOfReplicas=2)
* Третий сервер — управляющая нода (ArbitrationRank=2)

Выводы

Избыточность данных еще не гарантирует отказоустойчивость. Обязательно тестируйте конфигурации с использованием описанного выше аглоритма или путем физического отключения серверов.

Источник:  internet-technologies.ru [1]


Article printed from Все для CMS | Joomla, Drupal, phpBB, Wordpress, DLE, IPB: http://cmsart.ru

URL to article: http://cmsart.ru/articles/mysql-articles/povyishennaya-dostupnost-mysql-cluster-i-algoritm-arbitrazha

URLs in this post:

[1] internet-technologies.ru: http://cmsart.ru/goto/http://www.internet-technologies.ru

Copyright © 2012 Поддержка CMS | Документация, статьи по Joomla, Drupal, phpBB. All rights reserved.