Назад | Перейти на главную страницу

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

Настроить

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

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

В настоящее время существует рабочая конфигурация ведущий / ведомый от 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

Решение

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

Прочтите источник

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

Не забывайте читать исходники включенных файлов!

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

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

Заполните проклятые параметры

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

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

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

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

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

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

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

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