Это краткая заметка как настроить отказоустойчевый кластер с балансировкой нагрузки из 2 MySQL серверов. Исходные данные 2 свежеустановленных MySQL сервера. Необходимо настроить работу таким образом, что бы в нормальной ситуации запросы балансируются между MySQL серверами, в случае выхода из строя одного из MySQL серверов все запросы идут ко второму.



Для начала необходимо настроить репликацию 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

Автор: системный администратор компании Magvai69

Комментарии (4)


  1. youROCK
    28.08.2015 11:15
    +9

    Я бы категорически не рекомендовал использовать эту схему — отправьте 2 запроса подряд, которые меняют одни и те же данные несовместимым образом, и все — репликация встала. После того, как репликация встанет, чинить такой мастер-мастер будет тем сложнее, чем дольше продолжается то, что запросы раскидываются по разным мастерам — если приложение заранее к такому не подготовлено, количество конфликтов у вас будет продолжать расти.

    Если вам не слишком критична latency записи, я бы рекомендовал решения с синхронной репликацией — например, Galera Cluster или Percona XtraDB Cluster.

    Если же скорость выполнения insert/update критична, то лучше использовать master-slave (который можно сконфигурировать и как master-master, чтобы восттанавливаться из слейва было проще). В этом случае переключение с мастера на слейв нужно делать вручную, для сохранения консистентности данных


    1. akhaustov
      28.08.2015 11:16

      Спасибо за рекомендации. Попробуем применить.


      1. icCE
        28.08.2015 17:05
        +2

        Ну и для master-master — поставьте третий сервер. Спокойнее спать будите.


    1. Ingtar
      28.08.2015 18:26

      Например можно выставить в настройках HA-proxy активный сервер и пассивный.
      Тогда все запросы пойдут на одну ноду, но если что — то вот вам резервная нода.
      Главное следить во все глаза за статусом обоих мастеров :)