Ресурс главного / подчиненного кардиостимулятора MySQL не запускается на узлах кластера

Настроить

Я настраиваю кластер высокой доступности для веб-приложения, используя два физических сервера в управляемом кластере Corosync/Pacemaker.

Узнав, что я движусь не в ту сторону, я решил использовать встроенный агент MySQL-ресурса heartbeat для управления экземплярами MySQL в кластере.

В настоящее время существует рабочая конфигурация master/slave из node1 (текущий мастер) node2 (текущий раб). Теперь я хотел бы, чтобы Pacemaker управлял моими экземплярами MySQL, чтобы он мог продвигать / понижать мастер или слэйв.

Согласно этой (старой) вики-странице, я смогу выполнить настройку следующим образом:

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

Как видите, я немного изменил интервал для второго op monitor параметр, так как я знаю, что Pacemaker определяет действия по имени ресурса (здесь, p_mysql), название действия и интервал. Интервал был единственным способом отличить действие монитора на подчиненном узле от действия монитора на главном узле.

проблема

После внесения изменений в CID и открытие интерактивного crm_monЯ мог видеть, что Pacemaker не смог запустить ресурс на каждом узле. Смотрите прикрепленные скриншоты:

Извините, я не могу загрузить более 2 ссылок, потому что мне не хватает репутации... Скриншоты в комментариях

И он зацикливается снова и снова, пытаясь установить текущий мастер на ведомое устройство, текущий ведомый на ведомое устройство, а затем на ведущее устройство... Он явно зацикливается и не может правильно создать экземпляры MySQL.

Для справки, мой 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
Источник

1 ответ

Решение

Решение

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

Читать источник

Первое, что нужно сделать при настройке ресурсов высокой доступности, будет звучать типично, но RTFM. Не серьезно, узнайте, как работает программное обеспечение, которое вы планируете использовать. В этом конкретном случае моей первой ошибкой было недостаточно внимательно прочитать и понять, как работает агент ресурса (RA). Так как я использовал mysql РА предоставлено Heartbeat исходный скрипт RA был доступен в репозитории GitHub ресурсов-агентов ClusterLabs.

Не забудьте прочитать исходные файлы!

Убедитесь, что ваше программное обеспечение обновлено

Не был четко определен как проблема в моем конкретном случае, но, как gf_ & remote mind, всегда хорошо иметь версию вашего RA, которая работает с вашей версией программного обеспечения.

Заполните чертовы параметры

Правило номер один в HA: не полагайтесь на значения по умолчанию.

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

Именно здесь важна часть " Чтение исходного кода", поскольку она позволит вам по-настоящему понять, зачем нужны параметры. Однако, поскольку они часто описываются лишь кратко, возможно, вам придется пойти дальше, чем meta-data и найдите, где используются параметры. В моем случае это не сработало по нескольким причинам:

  • Я не указал путь к сокету, и путь по умолчанию для скрипта не соответствовал пути по умолчанию для моей системы (Debian 8).
  • Я не предоставил test_user, test_passwd: они присутствовали в meta-data но я думал, что мне это не нужно. После того, как я решил посмотреть, для чего он используется, я просто обнаружил, что эти параметры использовались для выполнения простого select count(*) в базе данных. И так как настройки по умолчанию установлены для использования пользователем root без пароля он не работал в моем случае (потому что в моих базах данных, root нужен пароль для подключения к базе данных). Этот конкретный шаг не позволил RA выполнить проверку, был ли текущий узел ведомым или нет.
  • Некоторые другие параметры также отсутствовали, и я знал, что они нужны мне только после того, как я обнаружил, где скрыты эти чертовы настройки по умолчанию.

Последнее слово

Опять же, большое gf_ за то, что gf_ время, чтобы исследовать со мной и предоставить gf_ для отладки моей установки.

Добиться хороших настроек HA не так-то просто (особенно если начинать с нуля), но при правильной настройке он может быть действительно мощным и обеспечить душевное спокойствие.

Примечание: душевное спокойствие не гарантируется;)

Источник
Другие вопросы по тегам