MariaDB MaxScale: настройка умного прокси перед кластером баз данных

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет эксплуатации MariaDB/MySQL в корпоративных проектах я перепробовал всё: HAProxy, ProxySQL, Galera Load Balancer, самописные скрипты failover. И чаще всего останавливался на MaxScale — когда требуется именно умный прокси, понимающий SQL. В дата-центре МТС у меня работают три инсталляции MaxScale перед Galera-кластерами на Dell Xeon Platinum 8280, которые держат десятки тысяч транзакций в час без единой ошибки failover.

Что делает MaxScale и зачем он нужен

MaxScale — это прокси от разработчиков MariaDB, который стоит между приложением и кластером БД. В отличие от HAProxy, он разбирает MySQL-протокол и принимает решения на основе типа запроса, состояния узлов, сессии пользователя.

• readwritesplit — разделение чтения и записи между мастером и репликами.
• Автоматический failover — при падении мастера promote нового, обновление бинарных логов, переключение клиентов.
• Мониторинг Galera — исключает из ротации узлы, отставшие по flow control.
• Query firewall — блокировка опасных запросов (DROP без WHERE, выход за лимит строк).
• Кэш запросов — ускорение часто повторяющихся SELECT без нагрузки на БД.

Установка MaxScale 23.08

# Ubuntu 22.04
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | \
  sudo bash -s -- --mariadb-maxscale-version="23.08"

apt update
apt install maxscale

# Проверка
maxscale --version
systemctl status maxscale

Подготовка пользователей на узлах БД

MaxScale нужно два сервисных аккаунта: один для чтения схем и мониторинга, второй для проксирования клиентских соединений. Создаются на любом узле Galera — репликация разнесёт.

-- Пользователь мониторинга
CREATE USER 'maxscale_mon'@'%' IDENTIFIED BY 'MonPass2026!';
GRANT SELECT ON mysql.user TO 'maxscale_mon'@'%';
GRANT SELECT ON mysql.db TO 'maxscale_mon'@'%';
GRANT SELECT ON mysql.tables_priv TO 'maxscale_mon'@'%';
GRANT SHOW DATABASES ON *.* TO 'maxscale_mon'@'%';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'maxscale_mon'@'%';
GRANT SLAVE MONITOR ON *.* TO 'maxscale_mon'@'%';

-- Пользователь проксирования
CREATE USER 'maxscale_router'@'%' IDENTIFIED BY 'RouterPass2026!';
GRANT SELECT ON mysql.* TO 'maxscale_router'@'%';
GRANT SHOW DATABASES ON *.* TO 'maxscale_router'@'%';

FLUSH PRIVILEGES;

Основной конфигурационный файл

# /etc/maxscale.cnf
[maxscale]
threads=auto
syslog=true
log_info=true

# Серверы Galera-кластера
[server1]
type=server
address=10.0.10.11
port=3306
protocol=MariaDBBackend

[server2]
type=server
address=10.0.10.12
port=3306
protocol=MariaDBBackend

[server3]
type=server
address=10.0.10.13
port=3306
protocol=MariaDBBackend

# Мониторинг Galera
[Galera-Monitor]
type=monitor
module=galeramon
servers=server1,server2,server3
user=maxscale_mon
password=MonPass2026!
monitor_interval=2s
available_when_donor=false
disable_master_failback=false

# Сервис с readwritesplit
[Galera-Service]
type=service
router=readwritesplit
servers=server1,server2,server3
user=maxscale_router
password=RouterPass2026!
max_slave_connections=100%
master_failure_mode=fail_on_write
causal_reads=true
transaction_replay=true

# Listener — точка входа для клиентов
[Galera-Listener]
type=listener
service=Galera-Service
protocol=MariaDBClient
port=4006

# Веб-интерфейс и REST API
[MaxAdmin-Listener]
type=listener
service=MaxInfo
protocol=HTTPD
port=8989

Запуск и проверка

systemctl enable --now maxscale
systemctl status maxscale

# Посмотреть состояние серверов
maxctrl list servers

# Состояние сервиса
maxctrl list services
maxctrl show service Galera-Service

# Статистика соединений
maxctrl list sessions

В выводе maxctrl list servers вы увидите роли: Master, Slave, Synced. При правильной настройке Galera один узел будет Master (куда идёт запись), остальные — Slave+Synced.

Master-Slave репликация: readconnroute

Для классического master-slave с асинхронной репликацией используется другой роутер — readconnroute. Он проще и быстрее, но не умеет разбирать транзакции.

[MySQL-Monitor]
type=monitor
module=mariadbmon
servers=master1,slave1,slave2
user=maxscale_mon
password=MonPass2026!
auto_failover=true
auto_rejoin=true
enforce_read_only_slaves=true

[Read-Service]
type=service
router=readconnroute
router_options=slave
servers=master1,slave1,slave2
user=maxscale_router
password=RouterPass2026!

[Write-Service]
type=service
router=readconnroute
router_options=master
servers=master1,slave1,slave2
user=maxscale_router
password=RouterPass2026!

[Read-Listener]
type=listener
service=Read-Service
port=4008

[Write-Listener]
type=listener
service=Write-Service
port=4009

Приложение подключается к 4008 для SELECT и к 4009 для INSERT/UPDATE/DELETE. Модульнее и предсказуемее, чем умный readwritesplit.

HA самого MaxScale через Keepalived

Один MaxScale — единая точка отказа. Я всегда ставлю минимум два экземпляра на разные виртуалки и связываю их через Keepalived с плавающим IP.

# /etc/keepalived/keepalived.conf на активном узле
vrrp_script check_maxscale {
    script "/usr/bin/systemctl is-active maxscale"
    interval 2
    weight 10
}

vrrp_instance VI_MAXSCALE {
    state MASTER
    interface ens18
    virtual_router_id 51
    priority 110
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass MaxScaleVRRP2026
    }
    virtual_ipaddress {
        10.0.10.100/24
    }
    track_script {
        check_maxscale
    }
}

На резервном узле те же настройки, только state BACKUP и priority 100. Приложение подключается к 10.0.10.100:4006 — и ничего не знает про переключения.

SSL между приложением и MaxScale

[Galera-Listener]
type=listener
service=Galera-Service
port=4006
ssl=required
ssl_cert=/etc/maxscale/certs/server-cert.pem
ssl_key=/etc/maxscale/certs/server-key.pem
ssl_ca_cert=/etc/maxscale/certs/ca-cert.pem
ssl_version=MAX

Кейс: MaxScale перед Galera для интернет-магазина

В феврале 2026 мы подключили MaxScale к Galera-кластеру клиента — интернет-магазин электроники на Битрикс24 с пиковой нагрузкой 450 запросов в секунду. До внедрения прокси приложение подключалось к одному узлу Galera; при его падении магазин лежал минут 5–15 (админ вручную менял IP в настройках). За 6 месяцев — три инцидента, суммарно 38 минут простоя.

Развернули пару MaxScale на двух виртуалках в дата-центре МТС, связали Keepalived с VIP 10.0.10.100. В настройках Битрикс24 заменили прямой IP БД на VIP. После внедрения:

• Чтение распределено по 3 узлам Galera, нагрузка на мастер упала на 65%.
• Два учения failover — клиент не заметил, сессии продолжились благодаря transaction_replay.
• Время отклика страниц каталога снизилось на 80 мс за счёт readwritesplit.

Стоимость внедрения — 65 000 руб, сопровождение — 12 000 руб/мес.

Мониторинг и типовые проблемы

• Следите за maxctrl show threads — длина очереди должна быть нулевой.
• Логи MaxScale в /var/log/maxscale/maxscale.log — там же видно, когда узел помечается как down.
• Prometheus-exporter для MaxScale доступен через порт 8989 и /metrics.
• Если приложение использует SET переменные и странные запросы ломают readwritesplit — отключите causal_reads и переведите на use_sql_variables_in=master.
• При конфликте клиентских паролей с MariaDB 10.11 используйте auth_login_validation_protocol=caching_sha2_password.

FAQ — MariaDB MaxScale

Чем MaxScale лучше HAProxy?

MaxScale понимает SQL-протокол, разделяет чтение/запись, делает failover. HAProxy работает на TCP.

Лицензия MaxScale коммерческая?

BSL: бесплатно до 3 серверов БД. Больше — коммерческая лицензия. Альтернатива — ProxySQL (GPLv3).

Как обеспечить HA самого MaxScale?

Два инстанса + Keepalived с плавающим VIP.

Какой порт использовать?

По умолчанию 4006 для readwritesplit.

MaxScale работает с PostgreSQL?

Нет. Для PostgreSQL — pgpool-II, pgbouncer или Patroni+HAProxy.