|
Chapter 9. 备份和恢复 Table of Contents 9.1. SQL 转储 9.1.1. 从转储中恢复 9.1.2. 使用 pg_dumpall 9.1.3. 大数据库 9.1.4. 注意 9.2. 文件系统级别的备份 9.3. 在不同版本之间迁移 和所有包含珍贵数据的东西相同，PostgreSQL 数据库也应该经常备份．尽管这个过程相当简单， 不过我们还是应该理解做这件事所 用的技巧和假设． 备份 PostgreSQL 数据有两个完全不同的方法： * SQL 转储 * 文件系统级别备份 9.1. SQL 转储 SQL 转储的方法采用的主意是创建一个文本文件，这个文本里面都是 SQL 命令，当把这个文件回馈给服务器时，将重建和转储时状态相同 的数据库． PostgreSQL 为这个用途提供了应用工具 pg_dump．这条命令的基本用法是： pg_dump dbname > outfile 正如你所见，pg_dump 把结果输出到标准输出． 我们下面就能看到这样做有什么好处． pg_dump 是个普通的 PostgreSQL 客户端应用（尽管是个相当聪明的东西．）这就意味着你能从 所有能访问该数据库的远端主机上面进行备份工作．不过请记住 pg_dump不会以所有特别权限运行．具体说来，就是 你必须要有你想备份的表的读权限，因此，实际上你几乎总是要成为 数据库终极用户． 要声明 pg_dump 应该以哪个用户身份进行联接，使用命令行 选项 -h host 和 -p port．缺省 主机是本地主机或你的环境变量PGHOST声明的值． 类似，缺省端口是环境变量PGPORT或（如果他 不存在的话）编译好了的缺省值．（比较方便的是，服务器通常有相同 的缺省．） 和所有其他 PostgreSQL 客户端应用相同， pg_dump 缺省时用和当前操作系统用户名同名的数据库用户 名进行联接．要覆盖这个名字，要么声明 -U 选项， 要么设置环境变量PGUSER． 请注意 pg_dump 的联接也和普通客户应用相同要 通过客户认证机制（在 Chapter 4）里描述． 由 pg_dump 创建的备份在内部是一致的， 也就是说，在pg_dump运行的时候对数据库的更新 将不会被转储．pg_dump 工作的时候并不阻塞 其他的对数据库的操作．（不过会阻塞那些需要排他锁的操作，比如 VACUUM FULL．） Important: 如果你的数据库结构依赖于 OID （比如说用做外键），那么你必须告诉 pg_dump 把 OID 也倒出来． 要倒 OID，能使用 -o 命令行选项． 缺省时也不会转储"大对象"．如果你使用大对象，请参考 pg_dump的命令手册页． 9.1.1. 从转储中恢复 pg_dump 生成的文本文件能由 psql 程式读取． 从转储中恢复的常用命令是 psql dbname < infile 这里的 infile 就是你 给pg_dump命令的 outfile 参数．这条命令不会创建数据库 dbname，你必须在执行psql 前自己从template0创建（也就是说，用命令 createdb -T template0 dbname）． psql 支持类似 pg_dump 的选项用以控制数据库服务器位置 和用户名．参考他的手册获取更多信息． 如果在原先数据库里的对象属于不同的用户，那么转储的文件会指示 psql 以各个受影响的用户轮流联接然后再创建相关的对象． 这样就保留了原来的所有权属性．不过这样也意味着所有这些用户必须 已存在，而且你还必须能够以每个用户的身份联接． 所以我们可能需要临时放松一下客户认证的设置． pg_dump 和 psql 能通过管道 读写，这样我们就可能从一台主机上将数据库目录转储到另一台主机上， 比如 pg_dump -h host1 dbname | psql -h host2 dbname Important: pg_dump生成的转储输出是相对于template0的．这就意味着所有 加入到template1的语言，过程等都会经由 pg_dump 转储．结果是，在恢复的时候，如果你使用的是客户化的template1， 那么你必须从template0中创建空的数据库，就象我们上面的例子那样． 9.1.2. 使用 pg_dumpall 上面的方法在备份整个数据库集群的时候比较麻烦而且不方便．因此我们 提供了 pg_dumpall 程式． pg_dumpall 备份一个给出的集群中的每个数据库，同时 还确保保留象用户和组这样的全局数据状态．调用 pg_dumpall 非常简单 pg_dumpall > outfile 象上面描写的那样，转储出的文件能用 psql 恢复． 不过这时候你绝对需要数据库终极用户权限，因为我们需要他来恢复 用户和组信息． 9.1.3. 大数据库 致谢: 最早由 Hannu Krosing （<hannu@trust.ee>）写于 1999-06-19。 因为 PostgreSQL 允许表的大小大于你的系统允许的最大文件大小， 可能把表转储到一个文件会有问题，因为生成的文件非常 可能比你的系统允许的最大文件大。 因为 pg_dump 输出到 stdout， 你能用标准的 *nix 工具绕开这个问题： 使用压缩的转储. 使用你熟悉的压缩程式，比如说 gzip． pg_dump dbname | gzip > filename.gz 用下面命令恢复： createdb dbname gunzip -c filename.gz | psql dbname 或 cat filename.gz | gunzip | psql dbname 使用 split．. 你能用下面的方法把输出分解成操作系统能接受的大小． 比如，让每个块大小为 1 兆字节： pg_dump dbname | split -b 1m - filename 用下面命令恢复： createdb dbname cat filename* | psql dbname 使用客户化转储格式. 如果PostgreSQL是在一个安装了zlib 压缩库的系统上制作的， 那么客户化转储格式将在写入输出文件的时候压缩数据． 对于大数据库而言，他会生成和使用gzip 类似的转储大小的文件， 不过还附加了一个好处：你能有选择地恢复库中的表． 下面的命令用客户化转储格式转储一个数据库： pg_dump -Fc dbname > filename 请参考 pg_dump 和 pg_restore 的手册获取细节． 9.1.4. 注意 pg_dump (及建筑在其上的 pg_dumpall)）有几个限制，这些限制的来源是 我们非常难从系统表中 重构某些信息． 具体说来，pg_dump 写对象的顺序并不复杂．这样可能 导致问题，比如说当把函数用做字段缺省值时．唯一的解决方法是 手工为转储重新排序．如果你在数据库设计里面创建了循环依赖 关系，那你就有更多事要做了． 出于向下兼容的考虑，缺省的时候 pg_dump 并不 转储大对象．要转储大对象，你必须使用客户化或 TAR 输出格式， 并且在 pg_dump 中使用-b选项． 参阅相应手册获取周详信息．在 PostgreSQL 源码树的 contrib/pg_dumplo 路径里也包含一个能转储大对象的 程式． 请熟悉一下 pg_dump 的手册页． 9.2. 文件系统级别的备份 另一个备份的策略是直接拷贝PostgreSQL用于存放数据库 数据的文件．我们在 Section 3.2 里解释了这些文件的位置，不过 如果你想用这个方法，你早就找到他们的位置． 你能用自己喜欢的所有常用文件系统备份的方法，例如 tar -cf backup.tar /usr/local/pgsql/data 不过，你要受到两个限制，令这个方法不那么实用，或至少 比 pg_dump 的方法逊色一些： 1. 为了进行有效的备份，数据库服务器必须被关闭． 象拒绝所有联接这样的折衷的方法是不行的，因为总是有一些 缓冲区数据存在． 同样的原因，我们也不建议信任那些声称支持 "连续快照（consistent snapshots）"的操作系统．有关关闭服务器的信息能在 Section 3.6里面找到． 相同，你在恢复数据之前也要关闭服务器． 2. 如果你原来深入了解了文件系统布局的细节，你可能试图从对应的 文件或目录里备份几个表或数据库． 这样做是没用的，因为包含在这些文件里的信息只是 部分信息．更有一半信息在提交日志文件 pg_clog/*里面，他包含所有事务的提交状态． 只有拥有这些信息，表文件的信息才是可用的．当然，试图 只恢复表和相关的 pg_clog 数据也是徒劳 的，因为这样会把数据库集群里的所有其他没有用的表的信息都拿出来． 还要说明的是，文件系统备份不会比SQL转储小．恰恰相反，大多数 情况下他要大．（比如pg_dump 不用 倒出索引，只是创建他们的命令．） |
|
|
