Это краткая заметка как настроить отказоустойчевый кластер с балансировкой нагрузки из 2 MySQL серверов. Исходные данные 2 свежеустановленных MySQL сервера. Необходимо настроить работу таким образом, что бы в нормальной ситуации запросы балансируются между MySQL серверами, в случае выхода из строя одного из MySQL серверов все запросы идут ко второму.
Для начала необходимо настроить репликацию MySQL типа master-master. Как это сделать, уверен найти не проблема. Так что опустим этот шаг. Что бы настроить балансировку, устанавливаем пакет HAProxy, socat (для просмотра статусов базы данных).
На одном из серверов, выполняем запрос, который создаст пользователя для просмотра статуса БД:
Теперь конфигурируем HAproxy, собственно сам конфиг, а потом немного комментариев:
option mysql-check user haproxy — задает под каким пользователя подключаться к mysql для проверки.
server server_db1 <FQDN сервера>:3306 weight 1 check inter 1s rise 3 fall 1 — задается отображаемое имя сервера, адрес сервера, количество проверок до перехода в состояние недоступности и сколько проверок до перехода в состояние доступен.
Ну и напоследок, для проверки состояния серверов из командной строки можно использовать команду:
Для начала необходимо настроить репликацию MySQL типа master-master. Как это сделать, уверен найти не проблема. Так что опустим этот шаг. Что бы настроить балансировку, устанавливаем пакет HAProxy, socat (для просмотра статусов базы данных).
На одном из серверов, выполняем запрос, который создаст пользователя для просмотра статуса БД:
INSERT INTO mysql.user (Host, User) values ('haproxy_ip', 'haproxy'); FLUSH PRIVILEGES;
Теперь конфигурируем HAproxy, собственно сам конфиг, а потом немного комментариев:
global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
stats socket /var/lib/haproxy/stats mode 777 level admin
listen mysql
bind 0.0.0.0:3306
timeout connect 10s
timeout client 1m
timeout server 1m
mode tcp
option mysql-check user haproxy
server server_db1 <FQDN сервера>:3306 weight 1 check inter 1s rise 3 fall 1
server server_db2 <FQDN сервера>:3306 weight 1 check inter 1s rise 3 fall 1
option mysql-check user haproxy — задает под каким пользователя подключаться к mysql для проверки.
server server_db1 <FQDN сервера>:3306 weight 1 check inter 1s rise 3 fall 1 — задается отображаемое имя сервера, адрес сервера, количество проверок до перехода в состояние недоступности и сколько проверок до перехода в состояние доступен.
Ну и напоследок, для проверки состояния серверов из командной строки можно использовать команду:
echo "show stat" | socat stdio /var/lib/haproxy/stats | cut -d, -f1,2,18,20,21
youROCK
Я бы категорически не рекомендовал использовать эту схему — отправьте 2 запроса подряд, которые меняют одни и те же данные несовместимым образом, и все — репликация встала. После того, как репликация встанет, чинить такой мастер-мастер будет тем сложнее, чем дольше продолжается то, что запросы раскидываются по разным мастерам — если приложение заранее к такому не подготовлено, количество конфликтов у вас будет продолжать расти.
Если вам не слишком критична latency записи, я бы рекомендовал решения с синхронной репликацией — например, Galera Cluster или Percona XtraDB Cluster.
Если же скорость выполнения insert/update критична, то лучше использовать master-slave (который можно сконфигурировать и как master-master, чтобы восттанавливаться из слейва было проще). В этом случае переключение с мастера на слейв нужно делать вручную, для сохранения консистентности данных
akhaustov
Спасибо за рекомендации. Попробуем применить.
icCE
Ну и для master-master — поставьте третий сервер. Спокойнее спать будите.
Ingtar
Например можно выставить в настройках HA-proxy активный сервер и пассивный.
Тогда все запросы пойдут на одну ноду, но если что — то вот вам резервная нода.
Главное следить во все глаза за статусом обоих мастеров :)