Репликация
Тема дорожной карты · PostgreSQL
Репликация PostgreSQL — процесс непрерывного копирования данных с основного сервера баз данных на один или несколько резервных серверов для обеспечения высокой доступности, аварийного восстановления и горизонтального масштабирования операций чтения. PostgreSQL поддерживает два основных режима репликации: физическая (потоковая) репликация, передающая WAL-поток байтов на резервные серверы, которые хранят точную побайтовую копию основного на уровне блоков, и логическая репликация, декодирующая WAL в изменения на уровне строк и способная реплицировать отдельные таблицы на гетерогенные целевые системы. Потоковая репликация настраивается установкой wal_level = replica в postgresql.conf, созданием слота репликации или пользователя репликации, а также указанием primary_conninfo на резервном сервере. Мониторинг задержки репликации через представление pg_stat_replication на основном сервере и pg_stat_wal_receiver на резервном — критически важная обязанность администратора баз данных для обеспечения своевременности обновления резервных серверов. Выбор между синхронной и асинхронной репликацией — управляемый параметрами synchronous_commit и synchronous_standby_names — является ключевым компромиссом между долговечностью данных и производительностью записи в 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 — долгий путь боли.