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 -X dbname < dumpfile
где dumpfile — файл, полученный командой pg_dump. База данных dbname не создается этой командой, поэтому ее необходимо создать самостоятельно перед исполнением команды psql (например, воспользовавшись командой createdb -T template0 dbname). Чтобы psql работал с настройками по умолчанию, используйте параметр -X (--no-psqlrc). psql поддерживает параметры, схожие с параметрами pg_dump, позволяющие указать адрес сервера базы данных и имя пользователя. За дополнительными сведениями обращайтесь к справочной странице psql. Дамп, отличный от текстового, восстанавливается с помощью утилиты pg_restore.
До начала восстановления дампа SQL необходимо удостовериться, что все пользователи, являющиеся владельцами объектов или имеющие права доступа к ним в резервируемой базе данных, уже созданы. В противном случае восстановление не сможет восстановить объекты с оригинальными правами владения и/или разрешениями.
По умолчанию сценарий psql продолжает исполнение даже при возникновении ошибки SQL. Для изменения этого поведения и остановки работы psql при появлении ошибки SQL с выходом со статусом 3 можно выполнить psql с переменной среды ON_ERROR_STOP:
psql -X --set ON_ERROR_STOP=on dbname < dumpfile
Результатом станет неполное восстановление базы данных. Альтернативным вариантом является указание, что весь дамп следует восстанавливать в рамках единой транзакции, обеспечивая полное завершение или полный откат восстановления. Режим единовременной транзакции активизируется добавлением параметров командной строки -1 или --single-transaction к psql. Применение этого режима подразумевает, что любая малозначимая ошибка способна вызвать откат продолжительного процесса восстановления. Иногда такой подход оказывается предпочтительнее ручного устранения последствий частичного восстановления сложных баз данных.
Способность pg_dump и psql читать и записывать данные через каналы позволяет производить прямую передачу базы данных с одного сервера на другой, например:
pg_dump -h host1 dbname | psql -X -h host2 dbname
Важно
Дамп, созданный с помощью pg_dump, ориентирован на шаблон template0. Это означает, что любые языки, процедуры и прочее, добавленные через template1, также войдут в дамп. Следовательно, при восстановлении необходимо создать пустую базу данных из template0, как показано выше.
После восстановления рекомендуется выполнить команду ANALYZE для каждой базы данных, чтобы планировщик запросов располагал полезными статистическими данными. За деталями обращайтесь к разделам «Обновление статистики планировщика» и «Сервис Autovacuum». Для рекомендаций по эффективному заполнению больших объемов данных в PostgreSQL обращайтесь к разделу «Заполнение базы данных».
Использование pg_dumpall
Утилита pg_dump осуществляет резервное копирование только одной базы данных за раз и не сохраняет информацию о ролях и табличных пространствах (так как они глобальны для всего кластера, а не индивидуальны для каждой базы данных). Для удобства выгрузки всего содержимого кластера баз данных предоставлена программа pg_dumpall. Она формирует резервную копию каждой базы данных кластера и дополнительно сохраняет глобальную информацию, такую как описания ролей и табличных пространств. Основная команда выглядит так:
pg_dumpall > dumpfile
Созданный дамп можно восстановить с помощью psql:
psql -X -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.