Структура и компоненты отказоустойчивого кластера Postgresql + Patroni + Pgbouncer + Haproxy + etcd

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

Компоненты кластера:

1. PostgreSQL — Основная база данных.
2. Patroni — Управляет высокодоступным кластером PostgreSQL, следит за состоянием кластера и осуществляет failover (переключение на резервную копию) при необходимости.
3. etcd (или Consul/Zookeeper) — Координирующая система распределенного консенсуса, которая помогает Patroni поддерживать распределенную информацию о состоянии кластера.
4. PgBouncer — Легковесный пул соединений для PostgreSQL, который уменьшает накладные расходы на создание и уничтожение подключений.
5. HAProxy — Балансировщик нагрузки, который управляет маршрутизацией трафика между PostgreSQL-кластером, следя за состоянием мастера и реплик.

Взаимодействие компонентов:

• PostgreSQL обеспечивает хранение данных и выполняет роль мастера (primary) или реплики (replica) в кластере.
• Patroni управляет состоянием узлов PostgreSQL. Используя данные от etcd (или другой системы координации), Patroni знает, какой узел является мастером, а какие — репликами. При отказе мастера Patroni автоматически переводит одну из реплик в роль мастера (failover).
• etcd хранит метаданные состояния кластера. Все узлы Patroni взаимодействуют с etcd для получения информации о текущем состоянии мастера, реплик и других метаданных, связанных с кластером.
• PgBouncer служит пулом соединений между приложениями и базой данных PostgreSQL. Он поддерживает устойчивые подключения, уменьшая нагрузку на базу данных при большом количестве подключений и переподключений.
• HAProxy действует как обратный прокси и балансировщик нагрузки. Он направляет трафик приложений к мастеру или репликам PostgreSQL, основываясь на метаданных о состоянии кластера от Patroni (через etcd).

Компоненты кластера и их функции:

1. PostgreSQL

• Основная база данных, которая выполняет хранение и обработку запросов.
• Мастер обрабатывает запросы на запись, а реплики могут обрабатывать запросы только на чтение (если настроено).

2. Patroni

• Функции:
  • Контролирует работу PostgreSQL-кластера.
  • Осуществляет автоматическое переключение на резервный узел при падении мастера (failover).
  • Обеспечивает лидерство в кластере, используя систему координации (etcd).
  • Поддерживает консистентное состояние кластера, автоматически поднимая новую реплику при добавлении нового узла или восстановлении упавшего.
• Основные задачи:
  • Управление состоянием PostgreSQL (мастер или реплика).
  • Мониторинг состояния PostgreSQL и координация через etcd.
  • Переключение мастера при сбое.

3. etcd

• Функции:
  • Распределённое хранилище для ключей/значений, обеспечивающее консенсус для Patroni.
  • Обеспечивает согласованность данных и отказоустойчивость за счёт репликации и поддержания кворума.
• Основные задачи:
  • Хранит метаданные кластера PostgreSQL, такие как текущий мастер, список реплик, их состояния.
  • Помогает Patroni синхронизировать информацию между узлами.

4. PgBouncer

• Функции:
  • Пул соединений, который уменьшает накладные расходы на подключение к PostgreSQL.
  • Уменьшает нагрузку на PostgreSQL за счет управления соединениями и временного хранения подключений от клиентов.
• Основные задачи:
  • Обеспечивает управление пулами соединений, поддерживая производительность кластера.
  • Перенаправляет запросы приложений на соответствующий узел PostgreSQL (мастер или реплика).

5. HAProxy

• Функции:
  • Обратный прокси-сервер и балансировщик нагрузки для PostgreSQL-кластера.
  • Перенаправляет запросы от клиентов на нужные узлы кластера, в зависимости от состояния (мастер или реплика).
  • Может использоваться для балансировки запросов на чтение между репликами.
• Основные задачи:
  • Проверка доступности мастера и реплик.
  • Маршрутизация запросов на запись к мастеру и запросов на чтение к репликам (если настроено).
  • Поддержка отказоустойчивости — если мастер выходит из строя, HAProxy перенаправляет трафик на новый мастер, который был выбран Patroni.

Архитектура кластера:

1. Кластер PostgreSQL:
   • Несколько узлов PostgreSQL: один в роли мастера (primary), остальные — реплики (standby/replica).
   • Мастер обрабатывает все запросы на запись, реплики могут обрабатывать запросы на чтение (опционально).
2. Patroni:
   • Запущен на каждом узле PostgreSQL.
   • Проверяет состояние локального узла (мастер или реплика) и взаимодействует с etcd для синхронизации состояния кластера.
   • При сбое мастера Patroni выбирает новую реплику для перевода в мастер.
3. etcd:
   • Кластер etcd (3 или более узлов для отказоустойчивости).
   • Обеспечивает координацию между узлами Patroni.
   • Хранит информацию о текущем мастере и репликах, что помогает Patroni координировать действия.
4. PgBouncer:
   • Локальный на каждом приложении или в отдельном узле между приложением и PostgreSQL.
   • Управляет пулом соединений для уменьшения нагрузки на PostgreSQL.
   • Может настроить маршрутизацию запросов на основе ролей узлов (мастер/реплика).
5. HAProxy:
   • Прокси-сервер, который передает запросы от приложения к нужному узлу PostgreSQL.
   • Маршрутизирует запросы на запись к мастеру, а запросы на чтение — к репликам.
   • Поддерживает отказоустойчивость, перенаправляя трафик на новый мастер при сбое предыдущего.

Основные процессы:

1. Инициализация кластера:
   • Patroni запускается на каждом узле PostgreSQL и взаимодействует с etcd для координации кластера.
   • Один из узлов становится мастером (primary), остальные — репликами.
2. Мониторинг состояния:
   • Patroni периодически проверяет состояние каждого узла PostgreSQL и обновляет информацию в etcd.
   • HAProxy использует эту информацию для маршрутизации запросов на мастер или реплики.
3. Failover:
   • Если мастер падает, Patroni выбирает новую реплику для его замены.
   • HAProxy и PgBouncer перенаправляют запросы на нового мастера, обеспечивая отказоустойчивость без остановки системы.
4. Балансировка запросов:
   • HAProxy может балансировать запросы на чтение между репликами, если это настроено, и все запросы на запись отправляются на мастер.

Эта архитектура обеспечивает высокую доступность, масштабируемость, низкие задержки благодаря пулингу соединений и отказоустойчивость через механизмы автоматического failover и балансировку нагрузки.