SQL-дампы
Эта страница переведена при помощи нейросети GigaChat.
Метод резервного копирования основан на формировании файла с командами SQL, которые при повторном вводе на сервер воссоздают базу данных в том же состоянии, в каком она находилась на момент создания дампа. PostgreSQL предоставляет утилиту pg_dump для реализации этого подхода. Стандартное использование команды выглядит следующим образом:
pg_dump dbname > dumpfile
Как видно, pg_dump направляет результат в стандартный вывод. Далее рассмотрим преимущества такого подхода. Несмотря на то, что представленная выше команда генерирует текстовый файл, pg_dump способен формировать файлы и в иных форматах, обеспечивающих параллельную обработку и тонкую настройку процесса восстановления объектов.
pg_dump является обычным приложением клиента PostgreSQL (хотя и особенно умным). Это означает, что можно выполнить эту процедуру резервного копирования с любого удаленного хоста, имеющего доступ к базе данных. Но помните, что pg_dump не работает со специальными разрешениями. В частности, у него должен быть доступ для чтения ко всем таблицам, где хотите создать резервную копию, поэтому чтобы сделать резервную копию всей базы данных, почти всегда приходится запускать его от имени суперпользователя базы данных. (Если недостаточные привилегии не позволяют создать резервную копию всей базы данных, возможен частичный резерв объектов, доступных пользователю, с применением параметров вроде -n schema или -t table.).
Для указания адреса сервера базы данных, к которому pg_dump должен подключиться, применяются параметры командной строки -h host и -p port. Сервер по умолчанию располагается на локальном узле или указан в переменной окружения PGHOST. Порт по умолчанию задается переменной окружения PGPORT или, при отсутствии таковой, значением, установленным при сборке программы. (Обычно сервер настроен аналогично.)
Как и любое другое клиентское приложение PostgreSQL, pg_dump подключается с именем пользователя базы данных, соответствующим текущему имени пользователя ОС. Переопределить это поведение можно указанием параметра -U или установкой переменной окружения PGUSER. Подключение pg_dump регулируется обычными правилами аутентификации клиентов (описанными в главе «Аутентификация клиентов»).
Значимым достоинством pg_dump перед прочими способами резервного копирования, описанными ниже, является возможность повторного воспроизведения результатов pg_dump в более свежих версиях PostgreSQL, тогда как методы резервного копирования на уровне файлов и архивация не зависят от конкретных версий сервера. Кроме того, pg_dump является единственным решением, совместимым с передачей базы данных на другую аппаратную платформу, например, при миграции с 32-битного сервера на 64-битный.
Дамп, сформированный с помощью pg_dump, внутренне согласован, то есть отражает мгновенный снимок базы данных на момент старта pg_dump. Работа pg_dump не препятствует выполнению прочих операций в базе данных. Исключение составляют операции, нуждающиеся в эксклюзивной блокировке, такие как многие формы ALTER TABLE.
Восстановление дампа
Текстовые файлы, полученные с помощью pg_dump, предназначены для обработки программой psql. Общий вид команды для восстановления дампа следующий:
psql dbname < dumpfile
где dumpfile — файл, полученный командой pg_dump. База данных dbname не создается этой командой, поэтому ее необходимо создать самостоятельно перед исполнением команды psql (например, воспользовавшись командой createdb -T template0 dbname). Psql поддерживает параметры, схожие с параметрами pg_dump, позволяющие указать адрес сервера базы данных и имя пользователя. За дополнительными сведениями обращайтесь к справочной странице psql. Дамп, отличный от текстового, восстанавливается с помощью утилиты pg_restore.
До начала восстановления дампа SQL необходимо удостовериться, что все пользователи, являющиеся владельцами объектов или имеющие права доступа к ним в резервируемой базе данных, уже созданы. В противном случае восстановление не сможет восстановить объекты с оригинальными правами владения и/или разрешениями.
По умолчанию сценарий psql продолжает исполнение даже при возникновении ошибки SQL. Для изменения этого поведения и остановки работы psql при появлении ошибки SQL с выходом со статусом 3 можно выполнить psql с переменной среды ON_ERROR_STOP:
psql --set ON_ERROR_STOP=on dbname < dumpfile
В любом случае будет только частично восстановленная база данных. В качестве альтернативы можно указать, что весь дамп должен быть восстановлен как одна транзакция, чтобы восстановление было либо полностью завершено, либо полностью отменено. Этот режим может быть указан путем передачи параметров командной строки -1 или --single-transaction к psql. При использовании этого режима имейте в виду, что даже незначительная ошибка может отменить восстановление, которое уже выполнялось в течение многих часов. Однако это все равно может быть предпочтительнее ручной очистки сложной базы данных после частичного восстановления дампа.
Способность pg_dump и psql читать и записывать данные через каналы позволяет производить прямую передачу базы данных с одного сервера на другой, например:
pg_dump -h host1 dbname | psql -h host2 dbname
Важно
Дампы, создаваемые с помощью pg_dump, являются относительными к template0. Это означает, что любые языки, процедуры и т.д., добавленные через template1, также будут сброшены с помощью pg_dump. В результате при восстановлении, если используется настроенный template1, то необходимо создать пустую базу данных из template0, как показано в примере выше.
После восстановления рекомендуется выполнить команду ANALYZE для каждой базы данных, чтобы планировщик запросов располагал полезными статистическими данными. За деталями обращайтесь к разделам «Обновление статистики планировщика» и «Сервис Autovacuum». Для рекомендаций по эффективному заполнению больших объемов данных в PostgreSQL обращайтесь к разделу «Заполнение базы данных».
Использование pg_dumpall
Утилита pg_dump осуществляет резервное копирование только одной базы данных за раз и не сохраняет информацию о ролях и табличных пространствах (так как они глобальны для всего кластера, а не индивидуальны для каждой базы данных). Для удобства выгрузки всего содержимого кластера баз данных предоставлена программа pg_dumpall. Она формирует резервную копию каждой базы данных кластера и дополнительно сохраняет глобальную информацию, такую как описания ролей и табличных пространств. Основная команда выглядит так:
pg_dumpall > dumpfile
Созданный дамп можно восстановить с помощью psql:
psql -f dumpfile postgres
На самом деле, можно указать любое существующее имя базы данных для начала работы, но если загрузка идет в пустой кластер, то обычно следует использовать postgres. Всегда необходимо иметь доступ к базе данных суперпользователя при восстановлении дампа pg_dumpall, так как это требуется для восстановления информации о роли и табличном пространстве. Если используются табличные пространства, убедитесь, что пути к табличным пространствам в дампе подходят для новой установки.
Pg_dumpall реализует свое функционирование путем отправки команд для рекреации ролей, табличных пространств и пустых баз данных, после чего вызывает pg_dump для каждой базы данных. Это означает, что хотя каждая отдельная база данных получает внутренний согласованный снимок, снимки различных баз данных не синхронизированы.
Отдельно можно произвести резервное копирование глобальной информации кластера с помощью опции pg_dumpall --globals-only. Это пригодится при полном резервном копировании кластера при самостоятельном запуске pg_dump для индивидуальных баз данных.
Обработка крупных баз данных
Некоторые операционные системы имеют ограничения на максимальный размер файла, которые вызывают проблемы при создании больших выходных файлов pg_dump. К счастью, pg_dump может записывать данные в стандартный вывод, поэтому можно использовать стандартные утилиты Unix для обхода этой потенциальной проблемы. Есть несколько возможных методов:
Используйте сжатые дампы. Можно использовать свою любимую программу сжатия, например gzip:
pg_dump dbname | gzip > filename.gz
Восстанавливайте с помощью:
gunzip -c filename.gz | psql dbname
или:
cat filename.gz | gunzip | psql dbname
Используйте split. Утилита split разбивает вывод на части меньших размеров, соответствующих лимитам файловой системы. Например, для разделения на фрагменты по 2 Гб:
pg_dump dbname | split -b 2G - filename
Затем восстановите командой:
cat filename* | psql dbname
При работе с GNU-версией утилиты split можно комбинировать ее с gzip:
pg_dump dbname | split -b 2G --filter='gzip > $FILE.gz'
Можно восстановить с помощью zcat.
Используйте специальный формат дампа pg_dump. Если PostgreSQL собран на системе с поддержкой библиотеки сжатия zlib, специальный формат дампа обеспечит компрессию данных при записи в выходной файл. Размер полученного дампа будет примерно соответствовать размеру, получаемому при использовании gzip, но отличается дополнительным преимуществом возможности выборочного восстановления таблиц. Приведенная ниже команда создает дамп базы данных в специальном формате:
pg_dump -Fc dbname > filename
Дамп специального формата не является скриптом для psql, а должен быть восстановлен с помощью утилиты pg_restore, например:
pg_restore -d dbname filename
Подробности можно найти на страницах справки pg_dump и pg_restore.
Для очень больших баз данных может потребоваться объединить split с одним из двух других подходов.
Используйте функцию параллельного резервного копирования pg_dump. Чтобы ускорить создание резервной копии большой базы данных, можете использовать режим параллельной работы pg_dump. Это позволит одновременно создавать резервные копии нескольких таблиц. Можно контролировать степень параллельности с помощью параметра -j. Параллельные дампы поддерживаются только для формата архива "каталог".
pg_dump -j num -F d -f out.dir dbname
Также можно использовать pg_restore -j для параллельного восстановления дампа. Работоспособность данного метода распространяется на любой архив, как в формате «настраиваемый», так и в формате «каталог», вне зависимости от того, использовался ли при создании дампа параметр pg_dump -j.