Потоковая репликация
Тема дорожной карты · PostgreSQL
Потоковая репликация — основной механизм PostgreSQL для непрерывного обеспечения высокой доступности и масштабирования чтения: резервный сервер подключается к основному по TCP-соединению и получает поток записей Write-Ahead Log (WAL) в реальном времени, применяя их для поддержания идентичной копии данных основного сервера. Для настройки потоковой репликации wal_level должен быть установлен в replica или logical в postgresql.conf, необходимо создать роль репликации с атрибутом REPLICATION, а primary_conninfo на резервном сервере должен указывать на основной. Задержка репликации — промежуток между изменением на основном и его применением на резервном — отслеживается через представление pg_stat_replication на основном сервере, показывающее для каждого подключённого резервного серверы значения sent_lsn, write_lsn, flush_lsn и replay_lsn. Синхронная потоковая репликация (synchronous_commit = on с настроенным synchronous_standby_names) гарантирует, что ни одна транзакция не фиксируется до получения подтверждения WAL хотя бы от одного резервного сервера, обеспечивая нулевую потерю данных ценой увеличенной задержки записи. Потоковая репликация в сочетании с инструментами повышения резервного — repmgr или Patroni — составляет основу большинства высокодоступных архитектур PostgreSQL в продуктивном администрировании баз данных.
Как это работает
Потоковая репликация копирует данные с primary на одну или несколько реплик. У Postgres есть streaming replication (WAL-записи по сети, обычно sub-second lag), logical replication (publish/subscribe на уровне таблицы, кросс-версионно, меньше фич). Реплики могут быть read-only "hot standby", обслуживая чтения; асинхронные (быстрые, можно потерять последние секунды при failover) или синхронные (zero data loss, медленнее запись). Инструменты: Patroni для HA-оркестрации, pgBackRest для бекапа + restore-as-replica.
Когда применять
Минимум одну streaming-реплику для любой production БД — служит failover-таргетом и местом для read-heavy запросов вне primary. Синхронная репликация — для финансовых/критичных данных, готовых обменять ~10ms write latency на zero data loss. Logical replication — для cross-version обновлений или выборочной репликации таблиц. Тестируйте failover до того, как он понадобится.
Типичные ошибки
Ловушки Потоковая репликация: расчёт "реплика = бекап" (DELETE на primary мгновенно реплицируется — бекапы + PITR отдельно); replication lag тихо растёт (нет мониторинга); нет автоматического failover (ручной MTTR = часы); реплика отстала слишком сильно, не догоняет (пересборка с нуля). Patroni или managed-предложение; своя HA — долгий путь боли.