У меня есть 2 сервера MySQL с репликацией мастер-мастер между ними. Репликация работает нормально.
Мне нужно настроить высокую доступность между ними, чтобы, если один из них выйдет из строя, другой взялся за дело.
Я следую этому руководству. https://towardsdatascience.com/high-availability-mysql-cluster-with-load-balancing-using-haproxy-and-heartbeat-40a16e134691
Проблема начинается, когда я пытаюсь добавить пользователя, который будет использоваться HAProxy для проверки состояния серверов MySQL server1 # mysql -u корень -p mysql> CREATE USER 'haproxy_check' @ '%';
Я получаю здесь ошибку политики паролей. Поскольку это производственный сервер, на котором размещены медицинские данные, из-за соответствия HIPAA я не могу иметь пользователя без пароля на сервере базы данных MySQL. Какой может быть альтернативный подход к этому.
Я бы не рекомендовал использовать архитектуру или системы, описанные в этом руководстве. Heartbeat был EOL в течение почти десяти лет, двухузловые кластеры мастер-мастер имеют надежду на устойчивость только в том случае, если вы используете высокоэффективное ограждение (поскольку нет надежды на кворум в двух узлах), что даже не затрагивается в этом руководстве. .
Кроме того, очень мало смысла в высокоактивном кластере на двух узлах - цель состоит в том, чтобы иметь возможность потерять узел, поэтому, если система «сбалансируется» между двумя репликами чтения / записи, обе системы должны принудительно применить максимальная загрузка нагрузки 40%. Гораздо более разумно и с меньшими накладными расходами использовать активную / пассивную систему, которая описывает одну первичную реплику для чтения / записи, при этом реплика только для чтения может быть продвинута.
Также важно установить более надежные гарантии стабильности кластера. чем полное отсутствие ограждений или кворума. Вместо того, чтобы выражать это с помощью Heartbeat, это можно выразить с помощью Pacemaker и Corosync. Третий (очень маленький) узел может использоваться для установления кворума - либо с помощью Galera, либо с помощью Corosync. Я бы предложил и то, и другое.
В качестве альтернативы Galera репликация базового хранилища и запуск только одного экземпляра SQL-сервера - очень быстрый вариант с низкими накладными расходами. Это можно сделать с помощью DRBD, Pacemaker и Corosync. Управление кластерами MySQL в Pacemaker - это то, что решается более десяти лет и работает очень надежно.
По крайней мере, у вас есть следующие варианты:
mysql-check
из конфигурации HAProxy. Проверка TCP сообщит HAProxy, прослушивает ли MySQL порт 3306 (что подразумевает, что он запущен), но не сможет ли он войти в систему. xinetd
и напишите сценарий, который обрабатывает вход в систему с локального компьютера. Это довольно просто. Что-то вроде следующего, хотя обратите внимание, что это не предназначено для использования как есть; команда MySQL должна быть настроена, пароль должен храниться в безопасном месте и т. д. По сути, это упрощенная версия того, что делает сценарий clustercheck
в Percona XtraDB. HAProxy выполнит http-check
порта, указанного в xinetd
, и посмотрит код ответа. #!/bin/sh
SEC=`mysql -u haproxy_check -pxxxxx -e "show slave status\G" 2>/dev/null | grep "Seconds_Behind_Master" | awk '{print $2}'`
if [ "${SEC}" == "" ] || [ ${SEC} -gt XX ]; then
echo -en "HTTP/1.1 503 Service Unavailable\r\n"
echo -en "Content-Type: text/plain\r\n"
echo -en "Connection: close\r\n"
echo -en "\r\n"
echo -en "Unavailable.\r\n"
sleep 0.1
exit 1
else
echo -en "HTTP/1.1 200 OK\r\n"
echo -en "Content-Type: text/plain\r\n"
echo -en "Connection: close\r\n"
echo -en "\r\n"
echo -en "Available.\r\n"
sleep 0.1
exit 1
fi
clustercheck
сценарий.