Ответ
В проекте с высоконагруженным кластером Galera для MariaDB мы использовали связку Keepalived и HAProxy для управления виртуальным IP (VIP) и интеллектуальной маршрутизации трафика. Это решение заменяло встроенный механизм выбора первичной ноды, который не всегда был стабилен при сетевых разделах.
Конфигурация Keepalived (VRRP):
# /etc/keepalived/keepalived.conf
vrrp_script chk_haproxy {
script "killall -0 haproxy" # Проверка, что процесс HAProxy жив
interval 2
weight -20
}
vrrp_instance VI_GALERA {
interface eth0
state MASTER # На других нодах — BACKUP
virtual_router_id 51
priority 101 # Приоритет для главной ноды
advert_int 1
authentication {
auth_type PASS
auth_pass secure_pass
}
virtual_ipaddress {
192.168.1.100/24 dev eth0
}
track_script {
chk_haproxy
}
}
Конфигурация HAProxy для проверки состояния Galera:
# /etc/haproxy/haproxy.cfg
backend galera_backend
mode tcp
balance leastconn
option tcp-check
tcp-check connect port 3306
tcp-check expect string mysql_native_password # Проверка ответа на аутентификацию
default-server inter 2s fall 3 rise 2
server galera-node-1 192.168.1.101:3306 check weight 100
server galera-node-2 192.168.1.102:3306 check weight 100
server galera-node-3 192.168.1.103:3306 check weight 100
frontend galera_frontend
bind 192.168.1.100:3306
default_backend galera_backend
Логика работы:
- Keepalived назначает VIP (
192.168.1.100) на ноду с наивысшим приоритетом, где работает HAProxy. - HAProxy направляет входящие SQL-запросы на одну из нод Galera, используя health checks для определения доступности и статуса репликации (
wsrep_local_state). - При падении активной ноды Keepalived переводит VIP на резервную ноду, обеспечивая отказоустойчивость на уровне сети.
Мы также оценивали Corosync/Pacemaker, но выбрали Keepalived+HAProxy из-за меньшей сложности, лучшей документации и отсутствия необходимости в выделенном кворуме дисков.