HAProxy: раздельное проксирования на мастер и реплики для Patroni кластера с Pgbouncer
Настройка HAProxy для проксирования запросов через PgBouncer в кластере Patroni включает использование механизма проверки состояния узлов с помощью HTTP-запросов (httpchk). Это нужно для того, чтобы проксировать запросы к правильным узлам, учитывая их роли (мастер или реплика). HAProxy проверяет состояние каждого узла через API Patroni и отправляет запросы либо на PgBouncer, который взаимодействует с мастером, либо на PgBouncer, который соединяется с репликами для чтения.
Шаги настройки HAProxy для Patroni кластера с PgBouncer
- PgBouncer — это пулер соединений, который может работать перед PostgreSQL для оптимизации использования соединений. Для настройки проксирования запросов через HAProxy на PgBouncer нужно, чтобы каждый PgBouncer был настроен для подключения либо к мастеру, либо к репликам PostgreSQL.
- Patroni — каждый узел Patroni предоставляет API, которое можно использовать для проверки, является ли узел мастером или репликой.
Пример конфигурации HAProxy
Проксирование на PgBouncer, подключенный к мастеру:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
frontend pgbouncer_master bind *:6432 mode tcp default_backend pgbouncer_master_backend backend pgbouncer_master_backend mode tcp option httpchk GET /master HTTP/1.1\r\nHost:\ localhost http-check expect status 200 default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions server pg_node1 192.168.1.101:6432 check port 8008 server pg_node2 192.168.1.102:6432 check port 8008 server pg_node3 192.168.1.103:6432 check port 8008 |
frontend pgbouncer_master— принимает запросы на порт 6432 и передает их на бэкенд, который проверяет состояние узлов через Patroni API.option httpchk GET /master— отправляет запрос/masterдля проверки, является ли узел мастером. Только мастер получит код ответа 200.- Серверы
pg_nodeX— это PgBouncer, работающие на каждом узле и подключающиеся к PostgreSQL через порт 6432.
Проксирование на PgBouncer, подключенный к репликам (только для чтения):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
frontend pgbouncer_readonly bind *:6433 mode tcp default_backend pgbouncer_replica_backend backend pgbouncer_replica_backend mode tcp option httpchk GET /replica HTTP/1.1\r\nHost:\ localhost http-check expect status 200 default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions server pg_node2 192.168.1.102:6432 check port 8008 server pg_node3 192.168.1.103:6432 check port 8008 |
frontend pgbouncer_readonly— проксирует запросы только на реплики для выполнения операций чтения.option httpchk GET /replica— проверяет, является ли узел репликой через запрос/replica.
Полная схема:
- PgBouncer:
- Каждый PgBouncer на узле Patroni подключен либо к мастеру, либо к репликам.
- PgBouncer работает на портах (например, 6432) и управляет пулом соединений с PostgreSQL.
- HAProxy:
- HAProxy использует HTTP-запросы к API Patroni для проверки состояния (мастер или реплика).
- Разделение входящих запросов на два фронтенда: для чтения (реплики) и записи (мастер).
Завершение
Этот подход позволяет гибко управлять запросами к кластеру PostgreSQL, распределяя их через PgBouncer в зависимости от роли узла. HAProxy будет проверять состояние узлов через Patroni API и направлять запросы на PgBouncer, который подключен к соответствующим узлам.
Recommended Posts
Плейбук Ansible по развертыванию haproxy
15.02.2024