Multi-state MySQL master/slave pacemaker resource fails to launch on cluster nodes
Setup
I'm setting up an HA cluster for a web application using two physical servers in a Corosync/Pacemaker managed cluster.
After finding out I was heading the wrong way, I decided to use heartbeat's bundled MySQL resource agent to manage my MySQL instances across the cluster.
Currently, there is a working master/slave configuration from node1 (current master) to node2 (current slave).
Now I would like Pacemaker to manage my MySQL instances so it can promote/demote master or slave.
According to this (old) wiki page, I should be able to achieve the setup by doing so:
primitive p_mysql ocf:heartbeat:mysql \
params binary="/usr/sbin/mysqld" \
op start timeout="120" \
op stop timeout="120" \
op promote timeout="120" \
op demote timeout="120" \
op monitor role="Master" timeout="30" interval="10" \
op monitor role="Slave" timeout="30" interval="20"
ms ms_mysql p_mysql \
meta clone-max=3
As you can see, I did however change slightly the interval for the second op monitor parameter, since I know Pacemaker identifies actions by Resource name (here, p_mysql), action name, and interval. The interval was the only way to differentiate the monitor action on a slave node from the monitor action on a master node.
Problem
After committing the changes to the CID and opening an interactive crm_mon, I could see that Pacemaker failed to start the resource on every node. See attached screenshots:
Sorry cannot upload more than 2 links because I do not have enough reputation yet... Screenshots in comments
And it loops over and over, trying to set the current master to a slave, the current slave to a slave, then to a master... It is clearly looping and fails to instantiate properly MySQL instances.
For reference, my crm configure show:
node 1: primary
node 2: secondary
primitive Failover ocf:onlinenet:failover \
params api_token=108efe5ee771368557869c7a837361a7c786f210 failover_ip=212.129.48.135
primitive WebServer apache \
params configfile="/etc/apache2/apache2.conf" statusurl="http://127.0.0.1/server-status" \
op monitor interval=40s \
op start timeout=40s interval=0 \
op stop timeout=60s interval=0
primitive p_mysql mysql \
params binary="/usr/sbin/mysqld" \
op start timeout=120 interval=0 \
op stop timeout=120 interval=0 \
op promote timeout=120 interval=0 \
op demote timeout=120 interval=0 \
op monitor role=Master timeout=30 interval=10 \
op monitor role=Slave timeout=30 interval=20
ms ms_mysql p_mysql \
meta clone-max=3
clone WebServer-clone WebServer
colocation Failover-WebServer inf: Failover WebServer-clone
property cib-bootstrap-options: \
dc-version=1.1.12-561c4cf \
cluster-infrastructure=corosync \
cluster-name=ascluster \
stonith-enabled=false \
no-quorum-policy=ignore
Решение
Благодаря людям, которые вместе со мной занимались исследованиями, я смог найти решение своей проблемы, и теперь у меня есть рабочая настройка. Если вы чувствуете себя достаточно смелым, вы можете прочитать комментарии к исходному вопросу, но вот краткое описание шагов, которые помогли мне решить мою проблему.
Читайте исходник
Первое, что нужно сделать при настройке ресурсов HA, будет звучать типично, но RTFM. Нет, серьезно, узнайте, как работает программное обеспечение, которое вы планируете использовать. В данном конкретном случае, моей первой ошибкой было то, что я не прочитал и не понял достаточно внимательно, как работает агент ресурсов (РА). Так как я использовал mysql RA, предоставляемый Heartbeat, скрипт с исходным RA был доступен на ClusterLabs' resource-агентах GitHub repo.
Не забудьте прочитать исходный код включенных файлов!
Убедитесь, что ваше программное обеспечение обновлено
Не было четко определено как проблема в моём конкретном случае, но как @gf_ и @remote mind предположили, всегда хорошо иметь версию RA, которая работает с вашей версией программного обеспечения.
Заполните.
.в чертовых параметрах
Number one rule in HA: не полагаться на значения по умолчанию.
Number one rule in HA: не полагаться на значения по умолчанию.
Это не так, иногда можно, но честно говоря, если бы я предоставил в RA каждый необязательный параметр, я бы исправил мою проблему намного быстрее .
Это на самом деле та часть Чтение исходного кода является важным, так как это позволит вам действительно понять, почему нужны параметры. Однако, поскольку они часто описываются лишь вкратце, вам, возможно, придется пойти дальше, чем meta-data и найти, где используются параметры. В моём случае, эта штука не сработала по нескольким причинам:
- я не указал путь к сокету, а для скрипта не соответствовала по умолчанию для моей системы (Debian 8).
- я не указал
test_user,test_passwd: они присутствовали вmeta-data, но я подумал, что они мне не нужны. После того, как я решил посмотреть, для чего он используется, я просто обнаружил, что эти параметры используются для выполнения простогоselect count(*)в базе данных. А так как по умолчанию используется userrootбез пароля, то в моем случае это не сработало (потому что в моих базах данныхrootнужен пароль для подключения к базе данных). Этот конкретный шаг не позволил РЦ выполнить проверку, является ли текущий узел ведомым или нет. - Некоторые другие параметры также отсутствовали, и я понял, что они мне нужны только после того, как обнаружил , где чертовы настройки по умолчанию были скрыты.
Заключительное слово
Еще раз большое спасибо @gf_ за то, что нашли время, чтобы вместе со мной исследовать и предоставить зацепки для отладки моей установки.
Хорошие настройки HA не так просты (особенно, если начать с нуля), но если хорошо настроенные могут быть действительно мощными и обеспечивать спокойствие.
Примечание: спокойствие не гарантировано ;)