Ответ
Я бы построил архитектуру на основе Patroni (для управления кластером) + etcd (для распределенного консенсуса) + HAProxy (для балансировки). Это проверенный стек для high availability.
Архитектура и компоненты:
- Patroni: Управляет жизненным циклом PostgreSQL-инстансов (promotion, failover, switchover). Он интегрируется с DCS (Distributed Configuration Store).
- etcd (или Consul): Выступает в роли DCS. Хранит состояние кластера (кто является лидером), обеспечивает кворум и координацию между нодами Patroni. Для отказоустойчивости развернул бы кластер из 3 или 5 нод.
- HAProxy с динамической конфигурацией: Балансировщик, который автоматически определяет мастер-ноду через Patroni REST API. Запросы на запись идут на мастера, чтение можно распределять по репликам.
- PgBouncer: Разместил бы перед каждой PostgreSQL-нодой для пулинга соединений, снижая нагрузку на БД.
- Бэкапы: Использовал бы WAL-G для непрерывной архивации WAL-файлов и периодических basebackup в объектное хранилище (например, S3 с Glacier для долгосрочного хранения).
- Инфраструктура: Все компоненты развернуты на выделенных виртуальных машинах (или bare metal) в разных зонах доступности. Под управлением IaC (Terraform).
Пример конфигурации Patroni (patroni.yml):
scope: prod-postgres-cluster
name: pg-node-1
restapi:
listen: 0.0.0.0:8008
connect_address: 10.0.1.10:8008
etcd:
hosts:
- 10.0.100.1:2379
- 10.0.100.2:2379
- 10.0.100.3:2379
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
initdb:
- encoding: UTF8
- locale: en_US.UTF-8
postgresql:
listen: 0.0.0.0:5432
connect_address: 10.0.1.10:5432
data_dir: /var/lib/postgresql/16/main
parameters:
wal_level: logical
hot_standby: "on"
max_connections: 500
Мониторинг: Prometheus для сбора метрик с Patroni, PostgreSQL и HAProxy, алертинг в Alertmanager, дашборды в Grafana.