Был ли у вас опыт кластеризации PostgreSQL?

«Был ли у вас опыт кластеризации PostgreSQL?» — вопрос из категории Базы данных, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Да, я настраивал отказоустойчивые кластеры PostgreSQL. Основной стек — Patroni в качестве менеджера кластера и etcd (или Consul/ZooKeeper) для распределенного хранилища конфигурации и лидер-элекции. Это решение обеспечивает автоматический failover.

Ключевые компоненты и задачи:

  1. Streaming Replication: Настройка асинхронной/синхронной репликации между мастером и репликами.
  2. Автоматический Failover: Patroni отслеживает состояние мастера и при его отказе автоматически продвигает одну из синхронных реплик в мастера, обновляя запись в DCS (etcd).
  3. Пул соединений: Использовал PgBouncer перед кластером для эффективного управления большим количеством подключений от приложений.
  4. Мониторинг: Интеграция с Prometheus (через экспортер postgres_exporter) и визуализация в Grafana для отслеживания лагов репликации, нагрузки и состояния здоровья.

Пример базовой конфигурации Patroni (patroni.yml):

scope: postgres-cluster-prod
name: pg-node-1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.0.1.10:8008

etcd:
  hosts: "10.0.1.1:2379,10.0.1.2:2379,10.0.1.3:2379"

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576 # 1 MB
    postgresql:
      use_pg_rewind: true
      parameters:
        wal_level: replica
        hot_standby: "on"
        max_wal_senders: 10
        wal_keep_size: 128MB

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.0.1.10:5432
  data_dir: /var/lib/postgresql/14/main
  bin_dir: /usr/lib/postgresql/14/bin