Я настраиваю кластер высокой доступности для веб-приложения, используя два физических сервера в управляемом кластере 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
и найдите, где используются параметры. В моем случае вещь не сработала по нескольким причинам:
test_user
, test_passwd
: они присутствовали в meta-data
но я думал, что мне это не нужно. После того, как я решил посмотреть, для чего он используется, я просто обнаружил, что эти параметры использовались для выполнения простого select count(*)
в базе данных. И поскольку по умолчанию установлено использование user root
без пароля в моем случае это не сработало (потому что в моих базах данных root
требуется пароль для подключения к базе данных). Этот конкретный шаг помешал RA выполнить проверку, был ли текущий узел ведомым или нет.Опять же, большое спасибо @gf_ за то, что потратили время на то, чтобы провести со мной расследование и предоставить потенциальных клиентов для отладки моей настройки.
Добиться хороших настроек высокой доступности не так-то просто (особенно если начинать с нуля), но при правильной настройке они могут быть действительно мощными и обеспечивать душевное спокойствие.
Примечание: душевное спокойствие не гарантируется;)