Представьте себе, что у вас есть неограниченный бюджет и вам нужно построить отказоустойчивый кластер PostgreSQL. Что вы будете использовать? Это должно быть не в Kubernetes

Архитектура отказоустойчивого кластера PostgreSQL с неограниченным бюджетом

При неограниченном бюджете можно построить максимально надежную и производительную систему, сочетающую проверенные паттерны с передовыми технологиями. Вот моя архитектура:

Физическая инфраструктура и размещение

Геораспределенная архитектура:

• 3 основных дата-центра в разных географических регионах с низкой сетевой задержкой (< 10 мс)
• 2 дополнительных резервных дата-центра на других континентах для disaster recovery
• В каждом основном ДЦ: отдельные стойки, источники питания, сетевые пути

Серверное оборудование:

• Выделенные серверы с процессорами AMD EPYC или Intel Xeon Scalable (минимум 64 ядра)
• 512 ГБ+ RAM с поддержкой ECC
• NVMe SSD корпоративного класса (Samsung PM9A3 или аналоги) для данных
• Отдельные накопители Intel Optane для WAL
• Сетевые карты 100 Гбит/с с RDMA поддержкой

Архитектура кластера базы данных

Многоуровневая репликация:

Основной кластер (3 узла в синхронной репликации):
- Узел 1 (Дата-центр A): Первичный мастер для записи
- Узел 2 (Дата-центр B): Синхронная реплика, готовый к failover
- Узел 3 (Дата-центр C): Синхронная реплика для кворума

Асинхронные реплики (5+ узлов):
- 2 узла в каждом основном ДЦ для read-only нагрузки
- 1 узел в каждом резервном ДЦ для disaster recovery

Выбор программного обеспечения и инструментов

PostgreSQL версия и расширения:

• PostgreSQL 16 с максимальными настройками надежности
• pglogical для логической репликации между основными центрами
• pg_partman для партиционирования больших таблиц
• PostGIS, TimescaleDB (если нужно) как расширения

Система управления и мониторинг:

• Patroni для автоматического failover и управления кластером
• etcd кластер (5 узлов) для distributed consensus
• HAProxy + Keepalived для балансировки соединений
• pgBackRest для распределенных бэкапов с дедупликацией
• Prometheus + Grafana + Alertmanager для мониторинга

Конфигурация репликации и восстановления

Настройка синхронной репликации в postgresql.conf:

synchronous_commit = remote_write
synchronous_standby_names = 'ANY 2 (node_b, node_c)'
wal_level = logical
max_wal_senders = 10
max_replication_slots = 10

Конфигурация Patroni (фрагмент):

scope: postgres-cluster-prod
name: node_a

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

etcd:
  hosts: ["10.0.1.100:2379", "10.0.1.101:2379", "10.0.1.102:2379"]

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    synchronous_mode: true
    postgresql:
      use_pg_rewind: true
      parameters:
        wal_level: logical
        hot_standby: "on"
        wal_keep_segments: 100
        max_wal_senders: 10

Стратегия резервного копирования

Многоуровневый подход:

1. Непрерывное WAL-архивирование в S3-совместимое хранилище (MinIO в каждом ДЦ)
2. Полные инкрементальные бэкапы ежедневно с pgBackRest
3. Логические дампы критических таблиц ежечасно
4. Snapshot-based бэкапы на уровне хранилища каждые 4 часа

Пример настройки pgBackRest:

[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=7
repo1-retention-archive=14
repo1-s3-bucket=postgres-backups
repo1-s3-endpoint=s3.datacenter-a.internal
repo1-s3-region=dc-a

[main]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432

[standby]
pg1-host=10.0.1.11
pg1-path=/var/lib/postgresql/16/main

Автоматизация и orchestration

Инфраструктура как код:

• Terraform для provisioning железа и сетей
• Ansible для конфигурации всех узлов
• Custom Python-скрипты для мониторинга lag и автоматического восстановления
• Hashicorp Vault для управления секретами и ротации паролей

Тестирование и валидация

Регулярные процедуры:

• Еженедельный автоматический failover тест
• Ежемесячное восстановление из бэкапа в isolated среде
• Load testing с помощью pgbench на 90% от production нагрузки
• Chaos engineering тесты (отключение сетевых линий, выключение серверов)

Сетевые аспекты

Выделенные сети:

• Репликационный трафик: отдельные физические интерфейсы 25 Гбит/с
• WAL shipping: отдельные пути через dark fiber
• Geo-replication: dedicated wavelength connections между ДЦ
• BGP anycast для клиентских подключений

Бюджетная оптимизация (несмотря на неограниченный бюджет)

Даже с неограниченным бюджетом важно обеспечить эффективность:

• Резервирование мощности на 3 года вперед со скидками
• Автоматическое масштабирование read-only реплик на основе нагрузки
• Разные классы хранилища для hot и cold данных
• Прогнозирование роста с помощью ML-моделей на основе исторических данных

Ключевые метрики SLA

• RPO (Recovery Point Objective): 0 секунд для синхронных реплик, 30 секунд для асинхронных
• RTO (Recovery Time Objective): < 30 секунд для failover между основными узлами, < 5 минут для полного восстановления ДЦ
• Доступность: 99.999% для операций чтения, 99.99% для операций записи
• Максимальный lag: < 100 МБ для синхронных реплик, < 1 ГБ для асинхронных

Такая архитектура обеспечивает максимальную отказоустойчивость через глубокое резервирование на всех уровнях: от физического железа до логической репликации данных. Геораспределенность защищает от региональных катастроф, а автоматизированное управление минимизирует человеческий фактор и время восстановления.