LINUX.ORG.RU
ФорумAdmin

MySQL + Pacemaker HA: выбор оптимального варианта


1

1

Собссно нужно поднять сабж, 2 ноды, режим работы - active/backup. Пока выбираю наиболее удачный вариант. В рассмотрении:

1) Классика - MySQL поверх DRBD. Плюсы - просто, проверено временем, минусы - при краше мастера возможно повреждение БД, лечится в принципе запуском mysqlcheck - но как реализовать его запуск только по failover миграции пока плохо представляю.

2) MySQL с асинхронной репликацией и скриптовыми костылями для синхронизации БД после подъема слэйва. Не хочется как-то...

2а) MySQL с уже готовыми костылями типа mysql-master-ha. Вроде как оно даже работает и даже howto есть, но насколько стабильно - вопрос.

2) MySQL с синхронной/полусинхронной репликацией. Насколько сильно будет проседать производительность БД при этом? Нагрузка вроде как не особо большая планируется (пока), но все же терзают сомнения...

Кто что посоветует?

★★★★★

"- при краше мастера возможно повреждение БД, лечится в принципе запуском mysqlcheck - но как реализовать его запуск только по failover миграции пока плохо представляю."

Создать lsb скрипт для с алгоритмом, который необходимо прогнать в случае если ресурс активируется на ноде. т.е. реализовать в нем mysqlcheck.
http://www.linux-ha.org/wiki/LSB_Resource_Agents
т.е. ресурсом который запускает софт кластера в случае failover будет являться скрипт с проверкой mysql таблиц.

Vlad-76 ★★★ ()
Ответ на: комментарий от Vlad-76

т.е. ресурсом который запускает софт кластера в случае failover будет являться скрипт с проверкой mysql таблиц.
затем стартует mysqld
последовательность старта скриптов задается в конфиге кластера
или засунуть старт СУБД в первый скрипт после проверки таблиц

Vlad-76 ★★★ ()
Ответ на: комментарий от Vlad-76

А что будет если база сломается так что mysqlcheck ее не починит? Мне вот кажется что исходить из того что «failover _может быть_ позволит рабодать дальше» недопустимо.

DRDB весьма стремная штука для репликации баз данных. Уж лучше сделать синхронную/асинхронную репликацию средствами движка базы.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Синхронная - интересует, насколько дольше будет выполняться запрос.

Асинхронная - потребует дополнительных костылей для синхронизации слэйва с мастером при его включении. Собссно вопросы по тому, как это реализовать. Пока что склоняюсь к mysql-master-ha - но интересует опыт его применения, и + пока слэйв засинкается с мастером система будет ненадежной (падение мастера = *опа).

DRBD - да, не лучший выбор, но в большинстве хауту рекомендуют его (скорее всего - еще с тех времен, когда мускул не умел репликацию).

NiTr0 ★★★★★ ()
Ответ на: комментарий от NiTr0

Синхронная - интересует, насколько дольше будет выполняться запрос.

Это покажут только ваши тесты, для вашей базы данных. Но если у вас там какой то важный cервис и важные данные, то нужна либо синхронная репликация либо двухфазный коммит. И совсем не факт что двухфазный коммит будет быстрее. Я бы вообще советовал не мускуль, а постгрес. Там хотя бы реализация репликации нормальная и для людей сделана.

А 99% howto описывают как сделать лишь бы работало. Редко кто задумывается о целостности данных, так что я бы опасался делать drdb. Кроме того часто гораздо лучше при поломке мастера таки прекращать сервис и руками переключать слейв в новый мастер, а не пользоваться автоматикой. Конечно если вам главное запрос обработать, а не иметь целостную базу, то тут уж все равно.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Это покажут только ваши тесты, для вашей базы данных.

БД - собссно не одна, а много всякого (веб-ресурсы, биллинг и т.п.), запросы в основном простые, без извращений, потому интересуют наблюдения тех, кто щупал.

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

С постгресом отдельная печальная песня по части автоматизации перевода слэйва в мастер, много возни однако...

Кроме того часто гораздо лучше при поломке мастера таки прекращать сервис и руками переключать слейв в новый мастер, а не пользоваться автоматикой.

Вот только высокодоступной такую систему не назвать даже с ооогромной натяжкой... А между тем эту БД будут использовать сервисы, для которых простой критичен.

+ ко всему, главная прелесть HA-кластера - отсутствие необходимости круглосуточного наблюдения за ним. В отличие от горячего резерва.

NiTr0 ★★★★★ ()
Ответ на: комментарий от realloc

Спасибо, посмотрю. На первый взгляд вроде стоящая вещь.

NiTr0 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.