Отказоустойчивость базы данных проверяется не в момент настройки репликации, а в момент аварии. И часто в самый неподходящий момент — посреди ночи или во время пиковой нагрузки. Поделюсь реальными историями и разбором полетов.

Типичный сценарий: праздничная распродажа, нагрузка на пике, и тут primary-база падает. Автоматический failover звучит заманчиво, но реальность сложнее. В одном проекте автофейловер сработал при кратковременном сетевом сбое, поднял новый primary, а когда связь восстановилась — в системе оказалось два мастера. Итог: split-brain и потерянные транзакции.

Теперь в критичных системах используем ручной failover с Patroni. Конфигурация выглядит так:

scope: postgres-cluster
namespace: /db/
name: postgres1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.0.0.1:8008

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.0.0.1:5432
  data_dir: /data/postgres
  bin_dir: /usr/lib/postgresql/14/bin

  parameters:
    max_connections: 100
    shared_buffers: 4GB
    wal_level: replica
    hot_standby: "on"

Каскадная репликация помогает снизить нагрузку на primary. Вместо десяти реплик, висящих на мастере, строим дерево: пара реплик первого уровня раздает WAL остальным. В PostgreSQL это настраивается через primary_conninfo:

-- На реплике первого уровня
primary_conninfo = 'host=10.0.0.1 port=5432'

-- На реплике второго уровня
primary_conninfo = 'host=10.0.0.2 port=5432'

Географически распределенные системы добавляют веселья. Латенция между дата-центрами может достигать сотен миллисекунд. Синхронная репликация в таких условиях убивает производительность. На практике работает схема с локальным кластером в каждом регионе и асинхронной репликацией между регионами.

Мониторинг репликации — отдельное искусство. Следим за метриками через Prometheus:

- job_name: 'postgres_exporter'
  static_configs:
    - targets: ['10.0.0.1:9187']
  metrics_path: /metrics
  params:
    query:
      - 'pg_replication_lag'
      - 'pg_wal_activity'

И обязательно тестируем failover. Регулярно. По графику. С записью времени переключения и подробным разбором каждого случая. Только так можно быть готовым к реальной аварии.

Из последних кейсов: база на 12TB с репликацией между континентами. Переключение на другой континент занимало 40 минут. Ускорили до 5 минут через комбинацию логической и физической репликации: основные таблицы реплицировали физически, а небольшие справочники — логически.

🏴‍☠️ @happy_devops