Nginx В Качестве Балансировщика Нагрузки Для Кластера Mysql Или Mariadb Galera

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

Разделение между главным и подчиненным устройствами больше не требуется, как это было в случае с классической репликацией MySQL. Nginx не предназначен для баз данных, поэтому вам придется прибегнуть к дополнительным настройкам, чтобы заставить кластер возвращать «дружественный» ответ проверки работоспособности.

Если вы используете HAProxy, сценарий проверки работоспособности на каждом сервере MySQL должен иметь возможность возвращать статус HTTP. Например, если сервер MySQL «чувствует себя хорошо», скрипт вернет статус HTTP 200 OK. В противном случае скрипт вернет 503 Сервис недоступен.

С помощью этих настроек HAProxy может обновить список маршрутизации и исключить «проблемные» серверы.

К сожалению, для проверки функциональности HAProxy использует xinetd в качестве демона, прослушивающего порт 9200. Эти конфигурации пока недоступны в nginx. Эта блок-схема иллюстрирует процесс определения работоспособности кластера Galera с настройкой с несколькими мастерами:



На момент написания NGINX Plus (платный) также поддерживал проверку работоспособности сервера, но без настройки специального порта.

Это фоновый скрипт, который проверяет работоспособность узла Galera и добавляет порт пересылки с помощью iptables, если узел работает должным образом (вместо возврата HTTP-ответа).

Этот скрипт можно использовать с другими балансировщиками TCP с ограниченными возможностями проверки работоспособности, такими как nginx (> 1.9), IPVS, Keepalived, Piranha, Distributor, Balance или Pen. Как он работает? Скрипт проверяет производительность на каждом узле кластера Galera раз в секунду.

Если узел работает в обычном режиме (wsrep_cluster_state_comment=Synced и read_only=OFF) или (wsrep_cluster_state_comment=Donor и wsrep_sst_method=xtrabackup/xtrabackup-v2), порт пересылки будет повышен с помощью iptables (по умолчанию 3308, с переадресацией на 3306).

Давайте установим скрипт и посмотрим, как он работает на практике: 1. На серверах баз данных — выполните следующие команды для установки скрипта:

$ git clone https://github.com/ashraf-s9s/clustercheck-iptables $ cp clustercheck-iptables/mysqlchk_iptables /usr/local/sbin

2. По умолчанию скрипт будет использовать пользователя MySQL «mysqlchk_user» с паролем «mysqlchk_password».

Мы должны убедиться, что пользователь существует и имеет необходимые права для проверки работоспособности.

Выполните эти команды на одном из узлов кластера (Galera выполнит их на остальных узлах).

mysql> GRANT PROCESS ON *.

* TO 'mysqlchk_user'@'localhost' IDENTIFIED BY 'mysqlchk_password'; mysql> FLUSH PRIVILEGES;

** Если вы хотите использовать другого пользователя или пароль, укажите его в аргументах -u и -p. Здесь здесь есть пример.

3. Для работы скрипту необходим iptables. В этом примере мы используем CentOS 7, где по умолчанию установлен firewalld. Нам нужно установить iptables-services:

$ yum install -y iptables-services $ systemctl enable iptables $ systemctl start iptables

Далее зададим основные правила для кластера MySQL Galera, чтобы iptables не влиял на связь с базой данных:

$ iptables -I INPUT -m tcp -p tcp --dport 3306 -j ACCEPT $ iptables -I INPUT -m tcp -p tcp --dport 3308 -j ACCEPT $ iptables -I INPUT -m tcp -p tcp --dport 4444 -j ACCEPT $ iptables -I INPUT -m tcp -p tcp --dport 4567:4568 -j ACCEPT $ service iptables save $ service iptables restart

4. После установки правил проверим их командой:

$ iptables -L -n

5. Протестируем mysqlchk_iptables:

$ mysqlchk_iptables -t Detected variables/status: wsrep_local_state: 4 wsrep_sst_method: xtrabackup-v2 read_only: OFF [11-11-15 08:33:49.257478192] [INFO] Galera Cluster Node is synced.

6. Выглядит хорошо.

Теперь давайте запустим скрипт как демон:

$ mysqlchk_iptables -d /usr/local/sbin/mysqlchk_iptables started with PID 66566.

7. Наши правила маршрутизации будут выглядеть примерно так:

$ iptables -L -n -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3308 redir ports 3306 Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination

8. Наконец, добавим в /etc/rc.local запуск скрипта, чтобы он запускался при старте сервера:

$ echo '/usr/local/sbin/mysqlchk_iptables -d' >> /etc/rc.local

В некоторых дистрибутивах стоит проверить, что rc.local имеет необходимые разрешения для запуска скрипта:

$ chmod +x /etc/rc.local

На стороне приложения убедитесь, что вы можете подключиться к базе данных через порт 3308. Повторите вышеуказанные шаги (кроме 2) на всех (оставшихся) узлах кластера.

Итак, с проверками производительности мы закончили, теперь перейдем к балансировке.

/configure --with-stream

3. Добавьте следующие строки в файл конфигурации nginx (

/usr/local/nginx/conf/nginx.conf

):

stream { upstream stream_backend { zone tcp_servers 64k; server 192.168.55.201:3308; server 192.168.55.202:3308; server 192.168.55.203:3308; } server { listen 3307; proxy_pass stream_backend; proxy_connect_timeout 1s; } }

4. Запускаем nginx:

$ /usr/local/nginx/sbin/nginx

5. Убедитесь, что nginx «слушает» порт 3307, как мы указали в конфигурации.

MySQL-соединения должны пройти через этот порт, после чего они будут переданы на порт 3308. Затем iptables (на узле) передаст запрос на порт 3306, где MySQL «слушает»:

$ netstat -tulpn | grep 3307 tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 5348/nginx: master

Большой! Мы установили nginx в качестве балансировщика нагрузки в кластере MySQL Galera. Перейдем к тестированию.

3. Уничтожили 2 других узла базы данных, чтобы g1.local стал неосновным.

4. Запустил g1.local из неосновного статуса.

5. Подключил остальные 2 узла.