pg_dump и pg_restore
Тема дорожной карты · PostgreSQL
pg_dump — утилита логического резервного копирования PostgreSQL, экспортирующая одну базу данных в SQL-скрипт или архив пользовательского формата, тогда как pg_restore повторно импортирует дампы пользовательского формата с гибкими параметрами для выборочного восстановления таблиц и параллельной загрузки. В отличие от pg_basebackup, выполняющего физическое двоичное копирование всего кластера, pg_dump создаёт переносимую, независимую от версии резервную копию, подходящую для миграций, клонирования сред и задач администрирования баз данных. Пользовательский формат (-Fc) является рекомендуемым выбором для продуктивных резервных копий, поскольку pg_restore может использовать несколько параллельных рабочих потоков (-j) для ускорения восстановления больших баз данных PostgreSQL. Для резервного копирования всего кластера, включая глобальные объекты — роли и пространства таблиц, — следует использовать pg_dumpall совместно с pg_dump. Регулярное тестирование процедур восстановления с помощью pg_restore — критически важная дисциплина настройки производительности и аварийного восстановления PostgreSQL.
Как это работает
pg_dump и pg_restore — цена MVCC. UPDATE и DELETE не удаляют строки — помечают dead; VACUUM возвращает место, ANALYZE обновляет статистику планировщика, REINDEX перестраивает раздутые индексы. autovacuum работает непрерывно по дефолту, но его триггеры консервативны для больших таблиц — тюньте autovacuum_vacuum_scale_factor, autovacuum_analyze_scale_factor per-table. VACUUM FULL переписывает таблицу (лочит записи!); pg_repack делает online. Смотрите pg_stat_user_tables.n_dead_tup для bloat.
Когда применять
Тюньте autovacuum агрессивно на горячих таблицах (например autovacuum_vacuum_scale_factor = 0.01 для миллион-строчных). Мониторьте bloat через pgstattuple или pgstatindex из pg_repack. pg_repack еженедельно на самых больших таблицах. Всегда ANALYZE после большой загрузки/миграции — старая статистика даёт плохие планы. Никогда VACUUM FULL под трафиком — лочит всю таблицу.
Типичные ошибки
Ловушки pg_dump и pg_restore: игнор autovacuum до 100GB таблицы с 50GB dead-строк; transaction wraparound — миф 200-летней давности, реальный (SELECT datname, age(datfrozenxid) FROM pg_database); неконтролируемый index bloat (запросы медленнее со временем при том же row count); VACUUM FULL в пик (CEO позвонит). Мониторьте + alerts на bloat-метрики с первого дня.