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

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

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

Что такое MaxScale, и почему он так крут? Это прокси-сервер, разработанный самими создателями MariaDB, который становится умным посредником между вашим приложением и кластером баз данных. В отличие от простого HAProxy, MaxScale не просто пропускает трафик: он глубоко разбирает 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. Он, конечно, проще и работает быстрее. Но есть нюанс: 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

Как приложение подключается? Всё просто: для всех операций SELECT оно использует порт 4008, а для INSERT/UPDATE/DELETE — порт 4009. Такая схема гораздо модульнее и, главное, предсказуемее, чем пытаться полагаться на «умный» readwritesplit, который иногда может преподнести сюрпризы.

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

Один MaxScale? Сразу скажу — это прямая дорога к единой точке отказа. А кто захочет рисковать, когда вся система может рухнуть из-за одного компонента? Мы, в ITFresh, так не работаем! Поэтому на нашей практике мы всегда разворачиваем как минимум два экземпляра 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-адрес в настройках. За последние полгода до нашего прихода они пережили три таких инцидента, потеряв в общей сложности 38 минут драгоценного рабочего времени на простои.

Что мы сделали? Развернули два экземпляра MaxScale на отдельных виртуалках прямо в дата-центре МТС, как мы и любим. Объединили их через Keepalived, назначив плавающий IP 10.0.10.100. А потом самое главное: в настройках Битрикс24 мы просто заменили старый прямой IP базы данных на этот новый VIP. И всё! Что получили после внедрения? Результаты говорят сами за себя:

• Теперь запросы на чтение равномерно распределены между тремя узлами 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.