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

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

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

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

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

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

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

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

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

Советую связку Pacemaker + Percona Replication Manager.

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

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

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

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

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

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

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

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

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

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

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