pg_basebackup
Тема дорожной карты · PostgreSQL
pg_basebackup — официальная утилита PostgreSQL для создания двоичной базовой резервной копии работающего кластера баз данных, формирующая согласованный снимок, служащий основой для восстановления на момент времени (PITR) и создания резервных серверов потоковой репликации. Инструмент подключается к основному серверу по протоколу репликации, требуя роль с атрибутом REPLICATION и соответствующую запись в pg_hba.conf, что делает его неотъемлемой частью администрирования баз данных при реализации стратегий резервного копирования. pg_basebackup одновременно передаёт файлы каталога данных и необходимые WAL-сегменты, поэтому резервная копия сразу готова к использованию в качестве резервного сервера без отдельного шага архивирования WAL, если wal_level установлен в replica или выше. Утилита поддерживает несколько форматов вывода — обычный каталог или единый tar-архив — и может создавать файл standby.signal, необходимый для настройки потоковой репликации в PostgreSQL 12 и новее. Регулярное использование pg_basebackup с проверкой процедур восстановления является лучшей практикой обеспечения аварийного восстановления и высокой доступности PostgreSQL.
Как это работает
pg_basebackup копирует данные с 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 до того, как он понадобится.
Типичные ошибки
Ловушки pg_basebackup: расчёт "реплика = бекап" (DELETE на primary мгновенно реплицируется — бекапы + PITR отдельно); replication lag тихо растёт (нет мониторинга); нет автоматического failover (ручной MTTR = часы); реплика отстала слишком сильно, не догоняет (пересборка с нуля). Patroni или managed-предложение; своя HA — долгий путь боли.