pg_dumpall
Описание
Утилита pg_dumpall предназначена для записи ("выгрузки") всех баз данных кластера PostgreSQL в один файл в формате скрипта. Этот файл содержит команды SQL, так что передав его на вход psql , можно восстановить все базы данных. Чтобы его сформировать, pg_dumpall вызывает для каждой базы данных в кластере pg_dump и дополнительно выгружает глобальные объекты, общие для всех баз данных. (Утилита pg_dump не сохраняет эти объекты.) В настоящее время, к таким объектам относятся группы, пользователи и табличные пространства, а также такие свойства, как права доступа, которые применяются к базам данных в целом.
Так как утилита pg_dumpall читает таблицы из всех баз данных, для получения полного содержимого баз запускать её, как правило, нужно от имени суперпользователя. Чтобы впоследствии выполнить сохранённый скрипт, также необходимо иметь права суперпользователя, позволяющие создавать пользователей, группы и собственно базы данных.
Генерируемый SQL-скрипт записывается в стандартное устройство вывода. Чтобы перенаправить его в файл, воспользуйтесь параметром [-f|file] или операторами оболочки.
Утилите pg_dumpall требуется подключаться к серверу PostgreSQL несколько раз (к каждой базе по отдельности). Если вы проходите проверку подлинности по паролю, вам придётся каждый раз вводить пароль. Чтобы избежать этого, удобно иметь файл ~/.pgpass. За дополнительными сведениями обратитесь к Разделу 31.15.
Параметры
Параметры командной строки для управления содержимым и форматом вывода.
- -a
--data-only Выгружать только данные, без схемы (определений данных).
- -c
--clean Добавить команды SQL для удаления (DROP) баз данных перед командами, создающими их. В дополнение к ним добавляются команды DROP для ролей и табличных пространств.
- -f имя_файла
--file=имя_файла Направить вывод в указанный файл. Если этот параметр опущен, скрипт записывается в стандартный вывод.
- -g
--globals-only Выгружать только глобальные объекты (роли и табличные пространства), без баз данных.
- -i
--ignore-version Устаревший флаг и сейчас игнорируется.
- -o
--oids Выгружать идентификаторы объектов (OIDs) вместе с данными таблиц. Используйте этот параметр, если в приложении есть ссылки на OID, например во внешних ключах. В противном случае, этот параметр лучше не использовать.
- -O
--no-owner Не генерировать команды, устанавливающие владение объектами, как в исходной базе данных. По умолчанию, pg_dumpall генерирует команды ALTER OWNER или SET SESSION AUTHORIZATION, восстанавливающие исходных владельцев для создаваемых элементов схемы. Однако выполнить эти команды сможет только суперпользователь (или пользователь, владеющий всеми объектами, создаваемыми скриптом). Чтобы получить скрипт, который сможет восстановить любой пользователь (но при этом он станет владельцем всех объектов), используется -O.
- -r
--roles-only Выгружать только роли, без баз данных и табличных пространств.
- -s
--schema-only Выгружать только определения объектов (схемы), без данных.
- -S имя_пользователя
--superuser=имя_пользователя Указать суперпользователя, который будет использоваться для отключения триггеров. Параметр имеет значение только вместе с --disable-triggers. Обычно его лучше не использовать, а запускать полученный скрипт от имени суперпользователя.
- -t
--tablespaces-only Выгружать только табличные пространства, без баз данных и ролей.
- -v
--verbose Включить режим подробных сообщений. В этом режиме pg_dumpall записывает в выходной файл время начала/завершения выгрузки, а в стандартный канал ошибок — сообщения о процессе. При этом подробные сообщения будет также выводить pg_dump.
- -V
--version Сообщить версию pg_dumpall и завершиться.
- -x
--no-privileges
--no-acl Не выгружать права доступа (команды GRANT/REVOKE).
- --binary-upgrade
Этот параметр предназначен для утилит обновления сервера. Использование для иных целей не рекомендуется и не поддерживается. Поведение параметра может быть изменено в последующих версиях без предварительного уведомления.
- --column-inserts
--attribute-inserts Выгружать данные в виде команд INSERT с явно задаваемыми именами колонок (INSERT INTO таблица (колонка, ...) VALUES ...). При этом восстановление будет очень медленным; в основном это применяется для выгрузки данных, которые затем будут загружаться не в PostgreSQL.
- --disable-dollar-quoting
Выключает экранирование тел функций с помощью знака доллара и принуждает к экранированию посредством стандартного синтаксиса SQL.
- --disable-triggers
Этот параметр действует только при выгрузке одних данных. С ним pg_dumpall добавляет команды, отключающие триггеры в целевых таблицах на время загрузки данных. Используйте его, если в ваших таблицах определены проверки ссылочной целостности или другие триггеры, которые вы не хотели бы выполнять в процессе загрузки данных.
В настоящее время команды, генерируемые с параметром --disable-triggers, должны исполняться от имени суперпользователя. Таким образом, необходимо также передавать флаг -S, либо при восстановлении выполнять скрипт от имени суперпользователя.
- --if-exists
Использовать условные команды (т. е. добавлять предложение IF EXISTS) при очистке базы данных и других объектов. Этот параметр принимается, только если также указан параметр --clean.
- --inserts
Выгружать данные в виде команд INSERT, а не COPY. При этом восстановление значительно замедлится; в основном это применяется для выгрузки данных, которые затем будут загружаться не в PostgreSQL. Заметьте, что восстановление может вовсе не выполниться при изменении порядка колонок в таблицах. В этом смысле параметр --column-inserts безопаснее, но восстановление будет ещё медленнее.
- --lock-wait-timeout=время_ожидания
Не ждать бесконечно получения разделяемых блокировок таблиц в начале процедуры выгрузки. Вместо этого, выдать ошибку, если не удастся заблокировать таблицы за указанное время_ожидания. Это время можно задать в любом из форматов, принимаемых командой SET statement_timeout. Допустимые значения зависят от версии сервера, выгружающего данные, но количество миллисекунд в виде целого числа принимают все версии, начиная с 7.3. Более ранние версии игнорируют этот параметр.
- --no-security-labels
Не выгружать метки безопасности.
- --no-tablespaces
Не выводить команды, создающие или выбирающие табличные пространства для объектов. С этим параметром все объекты будут созданы в пространстве по умолчанию, установленном во время восстановления.
- --no-unlogged-table-data
Не выгружать содержимое нежурналируемых таблиц. Этот параметр не влияет на то, как выгружаются определения этих таблиц (схема); он отключает только выгрузку данных из них.
- --quote-all-identifiers
Принудительно экранировать все идентификаторы. Может быть полезно при миграции на новую версию сервера, для избежания конфликтов с новыми резервными словами.
- --use-set-session-authorization
Выводить команды SET SESSION AUTHORIZATION, соответствующие стандарту, вместо ALTER OWNER, для назначения владельцев объектов. В результате выгруженный скрипт будет более стандартизированным, но может не восстановиться корректно, в зависимости от истории объектов.
- -?
--help Показать справку по аргументам командной строки pg_dumpall и завершиться.
Далее описаны параметры управления подключением.
- -d строка подключения
--dbname=строка подключения Указывает параметры подключения к серверу в формате строки подключения. См. Подраздел 31.1.1 для более подробной информации.
Этот параметр называется --dbname для согласованности с другими клиентскими приложениями, но так как pg_dumpall подключается не к одной базе данных, имя базы в строке подключения игнорируется. Чтобы указать имя базы данных, через подключение к которой будут выгружаться глобальные объекты и находиться другие выгружаемые базы, воспользуйтесь параметром -l.
- -h host
--host=host Указывает имя компьютера, на котором запущен сервер баз данных. Если значение начинается с косой черты, оно интерпретируется как имя каталога с доменным сокетом Unix. Значение по умолчанию берётся из переменной окружения PGHOST, если она установлена. В противном случае выполняется подключение к доменному сокету.
- -l база_данных
--database=база_данных Задаёт имя базы данных, через подключение к которой будут выгружаться глобальные объекты и находиться другие выгружаемые базы. По умолчанию используется postgres, а в случае её отсутствия — template1.
- -p порт
--port=порт Указывает TCP-порт или расширение локального файла Unix-сокета, на котором сервер слушает подключения. По умолчанию берётся значение переменной окружения PGPORT, если оно установлено, либо значение времени компиляции.
- -U имя_пользователя
--username=имя_пользователя Имя пользователя, под которым производится подключение.
- -w
--no-password Не выдавать запрос на ввод пароля. Если сервер требует аутентификацию по паролю и пароль не доступен с помощью других средств, таких как файл .pgpass, попытка соединения не удастся. Этот параметр может быть полезен в пакетных заданиях и скриптах, где нет пользователя, который вводит пароль.
- -W
--password Принудительно запрашивать пароль перед подключением к базе данных.
Это несущественный параметр, так как pg_dumpall запрашивает пароль автоматически, если сервер проверяет подлинность по паролю. Однако, чтобы понять это, pg_dumpall лишний раз подключается к серверу. Поэтому иногда имеет смысл ввести -W, чтобы исключить эту ненужную попытку подключения.
Заметьте, что пароль будет запрашиваться повторно для выгрузки каждой базы данных. Поэтому обычно лучше настроить файл ~/.pgpass, и не вводить пароль каждый раз вручную.
- --role=имя роли
Задаёт имя роли, которая будет осуществлять выгрузку. Получив это имя, pg_dumpall выполнит SET ROLE имя_роли после подключения к базе данных. Это полезно, когда проходящий проверку пользователь (указанный в -U) не имеет прав, необходимых для pg_dumpall, но может переключиться на роль, наделённую этими правами. В некоторых окружениях правила запрещают подключаться к серверу непосредственно суперпользователю, и этот параметр позволяет выполнить выгрузку, не нарушая их.
Переменные окружения
- PGHOST
PGOPTIONS
PGPORT
PGUSER Параметры подключения по умолчанию
Эта утилита, как и большинство других утилит PostgreSQL, также использует переменные среды, поддерживаемые libpq (см. Раздел 31.14).
Замечания
Так как pg_dumpall внутри себя вызывает pg_dump, часть диагностических сообщений будет относиться к pg_dump.
После восстановления имеет смысл запустить ANALYZE для каждой базы данных, чтобы оптимизатор получил актуальную статистику. Также можно запустить анализ для всех баз данных, выполнив команду vacuumdb -a -z.
При использовании pg_dumpall требуется, чтобы все необходимые каталоги табличных пространств существовали до восстановления; в противном случае, создание баз данных в нестандартном размещении завершится ошибкой.
Примеры
Чтобы выгрузить все базы данных, выполните:
$ pg_dumpall > db.out
Загрузить базы данных из этого файла можно так:
$ psql -f db.out postgres
(К какой базе данных вы подключаетесь, здесь не важно, так как скрипт, созданный утилитой pg_dumpall, будет содержать все команды, требующиеся для создания сохранённых баз данных и подключения к ним.)
См. также
Обратитесь к описанию pg_dump, чтобы узнать об условиях, при которых могут возникнуть проблемы.
| Пред. | Начало | След. |
| pg_dump | Уровень выше | pg_isready |
REINDEX
REINDEX — rebuild indexes
Synopsis
REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } name
Description
REINDEX rebuilds an index using the data stored in the index's table, replacing the old copy of the index. There are several scenarios in which to use REINDEX:
An index has become corrupted, and no longer contains valid data. Although in theory this should never happen, in practice indexes can become corrupted due to software bugs or hardware failures.
REINDEXprovides a recovery method.An index has become “bloated”, that is it contains many empty or nearly-empty pages. This can occur with B-tree indexes in Postgres Pro under certain uncommon access patterns.
REINDEXprovides a way to reduce the space consumption of the index by writing a new version of the index without the dead pages. See Section 24.2 for more information.You have altered a storage parameter (such as fillfactor) for an index, and wish to ensure that the change has taken full effect.
An index build with the
CONCURRENTLYoption failed, leaving an “invalid” index. Such indexes are useless but it can be convenient to useREINDEXto rebuild them. Note thatREINDEXwill not perform a concurrent build. To build the index without interfering with production you should drop the index and reissue theCREATE INDEX CONCURRENTLYcommand.
Parameters
INDEXRecreate the specified index.
TABLERecreate all indexes of the specified table. If the table has a secondary “TOAST” table, that is reindexed as well.
SCHEMARecreate all indexes of the specified schema. If a table of this schema has a secondary “TOAST” table, that is reindexed as well. Indexes on shared system catalogs are also processed. This form of
REINDEXcannot be executed inside a transaction block.DATABASERecreate all indexes within the current database. Indexes on shared system catalogs are also processed. This form of
REINDEXcannot be executed inside a transaction block.SYSTEMRecreate all indexes on system catalogs within the current database. Indexes on shared system catalogs are included. Indexes on user tables are not processed. This form of
REINDEXcannot be executed inside a transaction block.nameThe name of the specific index, table, or database to be reindexed. Index and table names can be schema-qualified. Presently,
REINDEX DATABASEandREINDEX SYSTEMcan only reindex the current database, so their parameter must match the current database's name.VERBOSEPrints a progress report as each index is reindexed.
Notes
If you suspect corruption of an index on a user table, you can simply rebuild that index, or all indexes on the table, using REINDEX INDEX or REINDEX TABLE.
Things are more difficult if you need to recover from corruption of an index on a system table. In this case it's important for the system to not have used any of the suspect indexes itself. (Indeed, in this sort of scenario you might find that server processes are crashing immediately at start-up, due to reliance on the corrupted indexes.) To recover safely, the server must be started with the -P option, which prevents it from using indexes for system catalog lookups.
One way to do this is to shut down the server and start a single-user Postgres Pro server with the -P option included on its command line. Then, REINDEX DATABASE, REINDEX SYSTEM, REINDEX TABLE, or REINDEX INDEX can be issued, depending on how much you want to reconstruct. If in doubt, use REINDEX SYSTEM to select reconstruction of all system indexes in the database. Then quit the single-user server session and restart the regular server. See the postgres reference page for more information about how to interact with the single-user server interface.
Alternatively, a regular server session can be started with -P included in its command line options. The method for doing this varies across clients, but in all libpq-based clients, it is possible to set the PGOPTIONS environment variable to -P before starting the client. Note that while this method does not require locking out other clients, it might still be wise to prevent other users from connecting to the damaged database until repairs have been completed.
REINDEX is similar to a drop and recreate of the index in that the index contents are rebuilt from scratch. However, the locking considerations are rather different. REINDEX locks out writes but not reads of the index's parent table. It also takes an ACCESS EXCLUSIVE lock on the specific index being processed, which will block reads that attempt to use that index. In contrast, DROP INDEX momentarily takes an ACCESS EXCLUSIVE lock on the parent table, blocking both writes and reads. The subsequent CREATE INDEX locks out writes but not reads; since the index is not there, no read will attempt to use it, meaning that there will be no blocking but reads might be forced into expensive sequential scans.
Reindexing a single index or table requires being the owner of that index or table. Reindexing a database requires being the owner of the database (note that the owner can therefore rebuild indexes of tables owned by other users). Of course, superusers can always reindex anything.
Examples
Rebuild a single index:
REINDEX INDEX my_index;
Rebuild all the indexes on the table my_table:
REINDEX TABLE my_table;
Rebuild all indexes in a particular database, without trusting the system indexes to be valid already:
$export PGOPTIONS="-P"$psql broken_db... broken_db=> REINDEX DATABASE broken_db; broken_db=> \q
Compatibility
There is no REINDEX command in the SQL standard.