# 24.1\. SQL转储 SQL转储的方法是创建一个文本文件，里面都是SQL命令， 当把这个文件回馈给服务器时，将重建与转储时状态一样的数据库。 PostgreSQL为这个用途提供了[pg_dump](#calibre_link-437)工具。 这条命令的基本用法是： ``` pg_dump _dbname_ > _outfile_ ``` 正如你所见，pg_dump把结果输出到标准输出。 我们下面就可以看到这样做有什么好处。 pg_dump是一个普通的PostgreSQL 客户端应用(尽管是个相当聪明的东西)。 这就意味着你可以从任何可以访问该数据库的远端主机上面进行备份工作。 但是请记住pg_dump不会以任何特殊权限运行。具体说来， 就是它必须要有你想备份的表的读权限，因此， 实际上你几乎总是要成为数据库超级用户。 要声明pg_dump应该以哪个用户身份进行连接， 使用命令行选项`-h``_host_`和`-p` `_port_`。 缺省主机是本地主机或环境变量 `PGPORT`声明的值。类似的，缺省端口是环境变量`PGPORT`或 (如果它不存在的话)编译好了的缺省值。服务器通常都有相同的缺省， 所以还算方便。 和任何其它PostgreSQL客户端应用一样，pg_dump缺省时用 与当前操作系统用户名同名的数据库用户名进行连接。 要覆盖这个名字，要么声明`-U`选项， 要么设置环境变量`PGUSER`。请注意pg_dump 的连接也和普通客户应用一样要通过客户认证机制(在[Chapter 19](#calibre_link-14)里描述)。 pg_dump超过后边描述的其它备份方法的一个重要优点 是pg_dump的输出通常可以 重新载入PostgreSQL新版本， 然而文件级别备份和连续归档都因 服务器版本而异。pg_dump是 将传输数据库到另一台机器体系结构工作时唯一的方法， 如从32位变到64位服务器。 由pg_dump创建的备份在内部是一致的， 也就是说，在pg_dump运行的时候转储的是数据库的快照。 pg_dump工作的时候并不阻塞其它的对数据库的操作 (但是会阻塞那些需要排它锁的操作，比如`ALTER TABLE`)。 > **Important:** 如果你的数据库结构依赖于OID(比如说用做外键)， 那么你必须告诉pg_dump把OID也导出来。要导出OID， 可以使用`-o`命令行选项。 ## 24.1.1\. 从转储中恢复 ``` psql _dbname_ < _infile_ ``` 这里的`_infile_` 就是通过pg_dump命令的文件输出。 这条命令不会创建`_dbname_`数据库， 你必须在执行psql前自己从 `template0`创建(也就是用`createdb -T template0` `_dbname_`命令)。 psql支持类似pg_dump的选项用以控制数据库服务器位置和用户名。 参阅[psql](#calibre_link-23)的手册获取更多信息。 在开始运行恢复之前，目标库和所有在转储出来的库中拥有对象的用户， 以及曾经在某些对象上被赋予权限的用户都必须已经存在。如果这些不存在， 那么恢复将失败，因为恢复过程无法把这些对象恢复成原有的所有权和/或权限。 有时候你希望恢复权限，不过通常你不需要这么做。 缺省时，psql脚本将在遇到错误的时候仍然继续执行。 你可能希望运行带有`ON_ERROR_STOP`变量设置的 psql以改变操作，并且如果发生SQL错误则带有 退出状态码3的psql退出。 ``` psql --set ON_ERROR_STOP=on dbname < infile ``` 不管上述哪种方法都只能得到部分恢复了的数据库。另外， 你可以将整个恢复过程当成一个单独的事务，这样就能够保证要么全部恢复成功， 要么全部回滚。可以通过向psql传递`-1`或者`--single-transaction`命令行 参数达到此目的。使用这个模式的时候即使一个很微小的错误也将导致已经运行 了好几个小时的恢复过程回滚。尽管如此，这种模式也比手动清除哪些不完整的 恢复数据强。 pg_dump和psql可以通过管道读写， 这样我们就可能从一台主机上将数据库目录转储到另一台主机上，比如： ``` pg_dump -h _host1_ _dbname_ | psql -h _host2_ _dbname_ ``` > **Important:** pg_dump生成的转储输出是相对于`template0`的。 这就意味着任何加入到`template1`的语言、 过程等都会经由pg_dump转储。 这样在恢复的时候，如果你使用的是自定义的`template1`， 那么你必须从`template0`中创建空的数据库， 就像我们上面的例子那样。 一旦完成恢复，在每个数据库上运行[ANALYZE](#calibre_link-589)是明智的举动， 这样优化器就有可用的统计数据了。 [Section 23.1.3](#calibre_link-446) 和[Section 23.1.6](#calibre_link-77)获取更多信息。 关于如何有效加载海量数据到PostgreSQL的更多信息， 参考[Section 14.4](#calibre_link-1190)。 ## 24.1.2\. 使用pg_dumpall pg_dump在一个时间只转储一个单独的数据库， 它不转储有关角色或表空间信息（因为这些是集群范围，而不是每个数据库）。 为了支持 方便转储整个数据库集群的全部内容。 因此我们提供了[pg_dumpall](#calibre_link-439)程序。 pg_dumpall备份一个给出的集群中 的每个数据库，同时还确保保留像角色和表空间这样的全局数据状态。 这个命令的基本用法是： ``` pg_dumpall > _outfile_ ``` 生成的转储可以用psql恢复： ``` psql -f _infile_ postgres ``` 实际上，你可以声明任意现有的数据库进行连接， 但是如果你是向一个空的数据库集群装载， 那么`postgres`应该是比较好的选择。 恢复pg_dumpall的转储的时候通常需要数据库超级用户权限， 因为我们需要它来恢复角色和表空间信息。如果使用了表空间， 需要注意转储中的表空间路径必须适合新的安装。 pg_dumpall的工作原理是发射命令来重新创建角色， 表空间和空数据库，然后为每个数据库调用pg_dump。 这意味着，虽然每个数据库内部一致， 但不同的数据库快照可能不是恰好同步。 ## 24.1.3\. 处理大数据库 当创建大的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`允许用下面的方法把输出分解成操作系统可以接受的大小。 比如，让每个块大小为1MB： ``` pg_dump _dbname_ | split -b 1m - _filename_ ``` 用下面命令恢复： ``` cat _filename_* | psql _dbname_ ``` **使用pg_dump自定义转储格式.** 如果PostgreSQL是在一个安装了zlib 压缩库的系统上制作的， 那么自定义转储格式将在写入输出文件的时候压缩数据。 它会生成和使用`gzip`类似大小的转储文件，但是还附加了一个优点： 你可以有选择地恢复库中的表。下面的命令用自定义转储格式转储一个数据库： ``` pg_dump -Fc _dbname_ > _filename_ ``` 自定义格式的转储不是脚本，不能用于psql，而是需要使用pg_restore转储。 比如： ``` pg_restore -d _dbname_ _filename_ ``` 请参阅[pg_dump](#calibre_link-437)和[pg_restore](#calibre_link-440)手册获取细节。 对于非常大的数据库，你可能需要结合`split`以及其他两种方法之一。 **使用pg_dump的并行转储功能.** 为了加快大数据库的转储，你可以使用pg_dump并行模式。 这将同时转储多个表。你可以使用`-j`参数控制并行性程度。 并行转储只支持"目录"归档模式。 ``` pg_dump -j _num_ -F d -f _out.dir_ _dbname_ ``` 你可以使用`pg_restore -j`并行恢复转储。这将为任何"自定义"或者 "目录"归档模式工作，是否它已经使用`pg_dump -j`创建。