IT заметки по программированию
IT заметки по программированию
IT заметки по программированию
IT заметки по программированию

HAProxy: раздельное проксирования на мастер и реплики для Patroni кластера с Pgbouncer

31.01.2024
Nginx, HAProxy, PostgreSQL
Комментариев нет

Настройка HAProxy для проксирования запросов через PgBouncer в кластере Patroni включает использование механизма проверки состояния узлов с помощью HTTP-запросов (httpchk). Это нужно для того, чтобы проксировать запросы к правильным узлам, учитывая их роли (мастер или реплика). HAProxy проверяет состояние каждого узла через API Patroni и отправляет запросы либо на PgBouncer, который взаимодействует с мастером, либо на PgBouncer, который соединяется с репликами для чтения.

Шаги настройки HAProxy для Patroni кластера с PgBouncer

  1. PgBouncer — это пулер соединений, который может работать перед PostgreSQL для оптимизации использования соединений. Для настройки проксирования запросов через HAProxy на PgBouncer нужно, чтобы каждый PgBouncer был настроен для подключения либо к мастеру, либо к репликам PostgreSQL.
  2. Patroni — каждый узел Patroni предоставляет API, которое можно использовать для проверки, является ли узел мастером или репликой.

Пример конфигурации HAProxy

Проксирование на PgBouncer, подключенный к мастеру:

INI
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, подключенный к репликам (только для чтения):

INI
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.

Полная схема:

  1. PgBouncer:
    • Каждый PgBouncer на узле Patroni подключен либо к мастеру, либо к репликам.
    • PgBouncer работает на портах (например, 6432) и управляет пулом соединений с PostgreSQL.
  2. HAProxy:
    • HAProxy использует HTTP-запросы к API Patroni для проверки состояния (мастер или реплика).
    • Разделение входящих запросов на два фронтенда: для чтения (реплики) и записи (мастер).

Завершение

Этот подход позволяет гибко управлять запросами к кластеру PostgreSQL, распределяя их через PgBouncer в зависимости от роли узла. HAProxy будет проверять состояние узлов через Patroni API и направлять запросы на PgBouncer, который подключен к соответствующим узлам.

Recommended Posts

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *