Note

pg_dump

pg_dump —将 PostgreSQL 数据库提取到脚本文件或其他归档文件中

Synopsis

pg_dump [ connection-option ...] [ option ...] [ dbname ]

Description

pg_dump 是用于备份 PostgreSQL 数据库的 Util。即使同时使用数据库,它也会进行一致的备份。 pg_dump 不会阻止其他用户访问数据库(读取器或写入器)。

pg_dump 只转储一个数据库。要备份群集中所有数据库通用的全局对象(例如角色和表空间),请使用pg_dumpall

转储可以脚本或存档文件格式输出。脚本转储是纯文本文件,其中包含将数据库重建到保存时所处状态所需的 SQL 命令。要从此类脚本还原,请将其提供给psql。脚本文件甚至可用于在其他机器和其他体系结构上重建数据库;进行了一些修改,甚至在其他 SQL 数据库产品上也是如此。

备用存档文件格式必须与pg_restore一起使用才能重建数据库。它们允许 pg_restore 对恢复什么有选择性,甚至可以在恢复之前对项目进行重新排序。存档文件格式设计为可跨体系结构移植。

当与一种存档文件格式一起使用并与 pg_restore 结合使用时,pg_dump 提供了一种灵活的归档和传输机制。 pg_dump 可用于备份整个数据库,然后 pg_restore 可用于检查存档和/或选择要还原数据库的哪些部分。最灵活的输出文件格式是“自定义”格式(-Fc)和“目录”格式(-Fd)。它们允许对所有已归档项目进行选择和重新排序,支持并行还原,并且默认情况下已压缩。 “目录”格式是唯一支持并行转储的格式。

在运行 pg_dump 时,应该检查输出是否有任何警告(按标准错误打印),尤其是考虑到以下列出的限制。

Options

以下命令行选项控制输出的内容和格式。

此选项类似于--section=data,但由于历史原因不同。

同时提供-b-B时,行为是输出大对象,转储数据时,请参见-b文档。

此选项仅对纯文本格式有意义。对于存档格式,可以在调用pg_restore时指定选项。

此选项仅对纯文本格式有意义。对于存档格式,可以在调用pg_restore时指定选项。

pg_dump 将打开* njobs * 1 个与数据库的连接,因此请确保max_connections设置足够高以容纳所有连接。

在运行并行转储时请求对数据库对象的排他锁可能导致转储失败。原因是 pg_dump 主进程对工作进程稍后将要转储的对象请求共享锁,以确保没有人删除它们并在转储运行时使它们消失。如果另一个 Client 端随后请求对表进行排他锁,则该锁将不会被授予,但会排队 await 主进程的共享锁被释放。因此,对该表的任何其他访问也不会被授予,并且将在排他锁定请求之后排队。这包括尝试转储表的工作进程。如果没有任何预防措施,这将是典型的僵局情况。为了检测到该冲突,pg_dump worker 进程使用NOWAIT选项请求另一个共享锁。如果未向工作进程授予该共享锁,则其他人在此期间必须已请求独占锁,并且无法 continue 进行转储,因此 pg_dump 别无选择,只能中止转储。

为了保持一致的备份,数据库服务器需要支持同步快照,这是 PostgreSQL 9.2 中针对主服务器引入的功能,针对备用服务器引入了 10 的功能。使用此功能,即使数据库 Client 端使用不同的连接,也可以确保他们看到相同的数据集。 pg_dump -j使用多个数据库连接;它通过主进程一次连接到数据库,并针对每个工作者作业再次连接到数据库。如果没有同步快照功能,则不能保证不同的工作作业在每个 Connecting 都看到相同的数据,这可能导致备份不一致。

如果要运行 9.2 之前版本服务器的并行转储,则需要确保从主服务器连接到数据库到最后一个工作者作业连接到数据库之间的时间里,数据库内容没有变化。最简单的方法是在开始备份之前,停止所有访问数据库的数据修改过程(DDL 和 DML)。当针对 9.2 之前的 PostgreSQL 服务器运行pg_dump -j时,还需要指定--no-synchronized-snapshots参数。

Note

指定-n时,pg_dump 不会尝试转储所选模式可能依赖的任何其他数据库对象。因此,不能保证特定模式转储的结果可以自己成功地恢复到干净的数据库中。

Note

指定-n时,不会转储非模式对象(例如 blob)。您可以使用--blobs开关将 blob 重新添加到转储中。

当同时提供-n-N时,行为是仅转储与至少一个-n开关匹配但不与-N开关匹配的架构。如果出现-N时没有-n,则将与-N匹配的模式从正常转储中排除。

此选项仅对纯文本格式有意义。对于存档格式,可以在调用pg_restore时指定选项。

此选项与--data-only相反。它类似于--section=pre-data --section=post-data,但由于历史原因不同。

(请勿将其与--schema选项混淆,该选项以不同的含义使用“模式”一词.)

要仅排除数据库中一部分表的表数据,请参见--exclude-table-data

使用-t-n-N开关无效,因为-t选择的表将被转储,而与那些开关无关,并且非表对象也将不被转储。

Note

指定-t时,pg_dump 不会尝试转储所选表可能依赖的任何其他数据库对象。因此,不能保证自己可以成功地将特定表转储的结果还原到干净的数据库中。

Note

-t开关的行为并不完全与 8.2 之前的 PostgreSQL 版本向上兼容。以前,编写-t tab会转储名为tab的所有表,但现在它只转储在默认搜索路径中可见的任何一个表。要获得旧的行为,您可以编写-t '*.tab'。同样,您必须编写类似-t sch.tab的内容以选择特定模式中的表,而不是-n sch -t tab的旧版本。

当同时提供-t-T时,行为是仅转储与至少一个-t开关匹配但不与-T开关匹配的表。如果出现-T时没有-t,则与-T匹配的表将从正常转储中排除。

当前,必须以超级用户身份执行为--disable-triggers发出的命令。因此,您还应该使用-S指定超级用户名,或者最好小心地以超级用户身份启动生成的脚本。

此选项仅对纯文本格式有意义。对于存档格式,可以在调用pg_restore时指定选项。

请注意,如果当前使用此选项,则可能还希望转储为INSERT格式,因为还原期间的COPY FROM不支持行安全性。

要排除数据库中所有表的数据,请参见--schema-only

此选项仅对纯文本格式有意义。对于存档格式,可以在调用pg_restore时指定选项。

数据部分包含实际表数据,大对象内容和序列值。数据后项目包括索引,触发器,规则和约束的定义,而不是经过验证的检查约束。前置数据项包括所有其他数据定义项。

此选项对仅用于灾难恢复的转储无益。这对于在原始数据库 continue 更新的同时用于装载数据库副本以进行报告或其他只读负载共享的转储很有用。没有它,转储可能会反映与最终提交的事务的任何串行执行都不相符的状态。例如,如果使用批处理技术,则在转储中批次可能显示为已关闭,而批次中的所有项目都不会出现。

如果在启动 pg_dump 时没有活动的读写事务,则此选项没有任何区别。如果读写事务处于活动状态,则转储的开始可能会延迟不确定的时间长度。运行后,无论有无切换,性能都是相同的。

当需要将转储与逻辑复制插槽(请参见Chapter 48)或并发会话同步时,此选项很有用。

在并行转储的情况下,将使用此选项定义的快照名称,而不是获取新的快照。

此选项对-N/--exclude-schema-T/--exclude-table--exclude-table-data无效。无法匹配任何对象的排除模式不视为错误。

以下命令行选项控制数据库连接参数。

如果此参数包含=符号或以有效的 URI 前缀(postgresql://postgres://)开头,则将其视为* conninfo *字符串。有关更多信息,请参见Section 33.1

这个选项从来都不是必须的,因为如果服务器要求密码认证,pg_dump 将自动提示 Importing 密码。但是,pg_dump 会浪费连接尝试,发现服务器需要密码。在某些情况下,值得 Importing-W以避免额外的连接尝试。

Environment

与大多数其他 PostgreSQLUtil 一样,该 Util 也使用 libpq 支持的环境变量(请参见Section 33.14)。

Diagnostics

pg_dump 内部执行SELECT语句。如果您在运行 pg_dump 时遇到问题,请确保能够使用例如psql从数据库中选择信息。同样,libpq 前端库使用的任何默认连接设置和环境变量都将适用。

pg_dump 的数据库活动通常由统计信息收集器收集。如果不希望这样,可以通过PGOPTIONSALTER USER命令将参数track_counts设置为 false。

Notes

如果您的数据库集群对template1数据库进行了本地添加,请注意将 pg_dump 的输出还原到一个 true 的空数据库中;否则,由于添加对象的重复定义,您很可能会出错。要创建没有任何本地添加的空数据库,请从template0而不是template1复制,例如:

CREATE DATABASE foo WITH TEMPLATE template0;

选择仅数据转储并使用选项--disable-triggers时,pg_dump 发出命令,以在插入数据之前禁用用户表上的触发器,然后发出命令,以在插入数据后重新启用它们。如果还原在中间停止,则系统目录可能处于错误状态。

pg_dump 生成的转储文件不包含优化程序用于制定查询计划决策的统计信息。因此,从转储文件还原后运行ANALYZE是明智的,以确保最佳性能。有关更多信息,请参见Section 24.1.3Section 24.1.6。转储文件也不包含任何ALTER DATABASE ... SET命令; pg_dumpall和数据库用户以及其他安装范围的设置一起转储了这些设置。

因为 pg_dump 用于将数据传输到 PostgreSQL 的较新版本,所以可以预期 pg_dump 的输出将加载到比 pg_dump 的版本新的 PostgreSQL 服务器版本中。 pg_dump 也可以从比它自己的版本旧的 PostgreSQL 服务器中转储。 (当前支持回到 8.0 版的服务器.)但是,pg_dump 不能从 PostgreSQL 服务器上转储比其主要版本更新的服务器。它将拒绝尝试,而不是冒险进行无效的转储。另外,不能保证 pg_dump 的输出可以加载到主版本较旧的服务器上-即使转储是从该版本的服务器上获取的也不行。将转储文件加载到较旧的服务器中可能需要手动编辑转储文件,以删除较旧的服务器无法理解的语法。在跨版本的情况下,建议使用--quote-all-identifiers选项,因为它可以防止由于不同 PostgreSQL 版本中的保留字列表不同而引起的问题。

转储逻辑复制订阅时,pg_dump 会生成使用connect = false选项的CREATE SUBSCRIPTION命令,因此恢复订阅不会构建用于创建复制插槽或初始表副本的远程连接。这样,可以还原转储而无需访问远程服务器的网络。然后由用户以合适的方式重新激活订阅。如果所涉及的主机已更改,则可能必须更改连接信息。在启动新的完整表副本之前,截断目标表也可能是适当的。

Examples

要将名为mydb的数据库转储到 SQL 脚本文件中,请执行以下操作:

$ pg_dump mydb > db.sql

要将这样的脚本重新加载到名为newdb的(新创建的)数据库中:

$ psql -d newdb -f db.sql

要将数据库转储到自定义格式的存档文件中:

$ pg_dump -Fc mydb > db.dump

要将数据库转储到目录格式的存档中:

$ pg_dump -Fd mydb -f dumpdir

要将数据库与 5 个工作作业并行转储到目录格式的存档中,请执行以下操作:

$ pg_dump -Fd mydb -j 5 -f dumpdir

要将存档文件重新加载到名为newdb的(新创建的)数据库中:

$ pg_restore -d newdb db.dump

要转储名为mytab的单个表:

$ pg_dump -t mytab mydb > db.sql

要在detroit模式中转储所有名称以emp开头的表,但名为employee_log的表除外:

$ pg_dump -t 'detroit.emp*' -T detroit.employee_log mydb > db.sql

转储名称以eastwest开头并以gsm结尾的所有模式,但名称中包含单词test的所有模式除外:

$ pg_dump -n 'east*gsm' -n 'west*gsm' -N '*test*' mydb > db.sql

同样,使用正则表达式表示法合并开关:

$ pg_dump -n '(east|west)*gsm' -N '*test*' mydb > db.sql

要转储除名称以ts_开头的表以外的所有数据库对象:

$ pg_dump -T 'ts_*' mydb > db.sql

要在-t和相关的开关中指定大写或大小写混合的名称,您需要将名称双引号;否则它将被折叠为小写(请参阅Patterns)。但是双引号对于 shell 来说是特殊的,因此反过来必须使用双引号。因此,要转储具有大小写混合名称的单个表,您需要

$ pg_dump -t "\"MixedCaseName\"" mydb > mytab.sql

See Also

pg_dumpall, pg_restore, psql

上一章 首页 下一章