High Availability в PostgreSQL

High Availability в PostgreSQL

Что такое High Availability

High Availability (HA) — архитектура, обеспечивающая работу БД при отказах компонентов. Цель: минимизировать downtime и потерю данных.

Основные компоненты HA

• Primary — основная БД (read/write)
• Standby — реплика (read-only)
• Failover — механизм переключения
• WAL (Write-Ahead Log) — журнал транзакций для репликации

Вариант 1: Streaming Replication (встроенный)

Настройка Primary

1. postgresql.conf:

wal_level = replica
max_wal_senders = 10
wal_keep_size = 1024  # MB
max_replication_slots = 10
hot_standby = on

2. pg_hba.conf:

host    replication     replicator      192.168.1.0/24        md5

3. Создать пользователя для репликации:

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'secure_password';

4. Базовая копия:

pg_basebackup -h primary-host -D /var/lib/postgresql/15/main -U replicator -P -Xs -R

5. Файл standby.signal (PostgreSQL 12+):

touch /var/lib/postgresql/15/main/standby.signal

6. recovery.conf (до PG12) или primary_conninfo в postgresql.auto.conf:

primary_conninfo = 'host=primary-host port=5432 user=replicator password=secure_password'
restore_command = 'cp /var/lib/postgresql/archive/%f %p'

Проверка

-- На primary
SELECT * FROM pg_stat_replication;

-- На standby
SELECT pg_is_in_recovery();
SELECT * FROM pg_stat_wal_receiver;

Вариант 2: Patroni (рекомендуемый)

Архитектура

• Patroni — управляет кластером
• DCS (etcd/Consul/ZooKeeper) — хранит состояние
• Streaming Replication — репликация

Установка

# Ubuntu/Debian
apt install patroni python3-etcd

# CentOS
yum install patroni python3-etcd

Конфигурация (patroni.yml)

scope: postgres
namespace: /service/
name: postgresql-01

restapi:
  listen: 0.0.0.0:8008
  connect_address: 192.168.1.10:8008

etcd:
  host: 192.168.1.1:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    postgresql:
      use_pg_rewind: true
      use_slots: true
      parameters:
        wal_level: replica
        hot_standby: on
        max_wal_senders: 10
        max_replication_slots: 10
  initdb:
  - encoding: UTF8
  - data-checksums
  pg_hba:
  - host all all 0.0.0.0/0 md5
  - host replication replicator 192.168.1.0/24 md5

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 192.168.1.10:5432
  data_dir: /var/lib/postgresql/15/main
  authentication:
    replication:
      username: replicator
      password: secure_password
    superuser:
      username: postgres
      password: postgres_password

Запуск

patroni patroni.yml

Управление

# Статус кластера
patronictl -c patroni.yml list

# Failover вручную
patronictl -c patroni.yml failover

# Switchover
patronictl -c patroni.yml switchover

Вариант 3: repmgr

Установка

apt install repmgr postgresql-15-repmgr

Инициализация кластера

# На primary
repmgr primary register

# На standby
repmgr standby clone --host=primary-host
repmgr standby register

Failover

repmgr standby promote
repmgr standby follow --new-primary-id=2

Вариант 4: pg_auto_failover (Citus Data)

Особенности

• Single master, multiple replicas
• Автоматический failover за 5-10 секунд
• Мониторинг через pg_auto_failover monitor

Установка

apt install pg-auto-failover

Инициализация

# Monitor
pg_auto_failover monitor --run

# Primary
pg_auto_failover primary --run --pgdata /var/libpostgresql/15/main

# Standby
pg_auto_failover standby --run --pgdata /var/lib/postgresql/15/main

Выбор решения

Рекомендации

Для production

• Patroni + etcd — лучший выбор для большинства сценариев
• Минимум 3 узла etcd для quorum
• Отдельные диски для WAL
• Мониторинг репликационной задержки

Настройки репликации

# Минимальная потеря данных
synchronous_commit = on
max_wal_senders = 10
wal_keep_size = 2048

# Производительность
synchronous_standby_names = 'ANY 1 (replica1, replica2)'

Мониторинг

• Patroni API: /cluster, /history
• Prometheus: patroni_exporter
• Алёрты: задержка репликации > 100MB, недоступность primary

Тестирование failover

1. Регулярно тестируйте failover
2. Документируйте процедуру
3. Тренируйте команду
4. Проверяйте целостность данных после failover

Распространённые ошибки

1. Нет мониторинга репликации — узнаёте об отказе слишком поздно
2. Недостаточный wal_keep_size — standby не может догнать
3. Нет testing failover — в production всё ломается
4. Single point of failure — etcd тоже должен быть HA
5. Нет бэкапов — HA ≠ backup

Чек-лист HA

• Настроена streaming replication
• Failover механизм (Patroni/repmgr)
• Мониторинг репликации
• Тестирование failover (минимум раз в месяц)
• Отдельные бэкапы (HA ≠ backup)
• Документация процедуры восстановления
• Тренированная команда

High Availability — это не только технология, но и процессы. Настройте мониторинг, тестируйте регулярно и документируйте всё.