pgsql的备份和恢复:备份:

1.pg_dump:(sql转储,类似于mysql的binlog的dump,可以加上压缩如gzip,可以设置压缩级别)备份:pg_dump dbname > outfile

恢复:psql dbname < infile

outfile 和infile是同一个文件

2.pg_dumpall:(sql转储,导出所有的db)

备份:pg_dumpall -f outfile

恢复:psql -f outfile postgres

3.pitr:在线备份,和oracle的归档原理差不多.

archive(归档文件):database manager 把query语句记录在  archive文件里,archive文件一般有多个,有固定大小.采取轮循的方式写.然后到了触发一定条件的时候,如:记录了1个小时的query语句了或者写满了1/2的时候.就执行这些query语句并把结果写到数据文件里.即记录到硬盘中.1.要使用pitr,必须打开pgsql的归档模式(archive)

在postgresql.conf文件中,设置如下:

# - Archiving -

archive_mode = on               # allows archiving to be done

# (change requires restart)

archive_command = 'cp "%p" /usr/local/pgsql/backup/"%f"'

# command to use to archive a logfile segment

archive_timeout = 60            # force a logfile segment switch after this

# time; 0 is off

2.以postgres身份连接到pgsql

psql 要备份的dbname

3.发出备份命令

select pg_start_backup('label');  --> 备份archive文件.

label --> 备份标签,一般为放置备份文件的全路径.如: /usr/local/pgsql/backup

4.执行备份

用tar或者cpio备份数据文件.此过程中,不用关闭数据库,也不用断开连接.

5.再以postgres身份连接到pgsql

select pg_stop_backup(); --> 终止备份archive文件.

这将终止备份模式,并自动切换到下一个归档文件.这样的好处是可以立即为下次备份做好准备.

4.pitr的即时恢复

1.停止pgsql服务

2.最好copy /usr/local/pgsql/data 到临时位置,以防万一.

3.清理掉data 文件下所有文件,如果用到tablespace,还得清掉表空间目录下的所有文件.

4.用正确的所有者恢复数据库文件.用postgres最好.

5.清理pg_xlog目录里的文件.删掉文件,保留文件夹

6.copy archive文件到pg_xlog文件夹下.

7.在集群数据目录/usr/local/pgsql/data里创建一个恢复命令文件recovery.conf。模版文件recovery.conf.sample在tarball的src里.

restore_cmd  -->    恢复的命令

recovery_target_time -->声明恢复到哪个时间戳

recovery_target_xid --> 声明恢复到哪个事物id

recovery_target_inclusive  --> 声明是在恢复目标之前还是之后停止.

recovery_target_timeline --> 声明恢复到一个时间线.

还需要临时修改 pg_hba.conf 以避免普通用户连接，直到你确信恢复已经正常了为止。

8.所有这些操作的关键是设置一个恢复命令文件，这个文件描述你希望如何恢复以及恢复应该走到哪里。

你可以使用 recovery.conf.sample(通常安装在安装目录的 share/ 子目录里)作为原型。

你必须在 recovery.conf 里面声明的一个东西是 restore_command ，它告诉系统如何拿回归档的 WAL 文件段。

类似 archive_command ，这个是一个脚本命令字符串。它可以包含 %f ，这个变量会被需要的日志文件名替换，以及 %p ，

它会被要拷贝去的日志文件的绝对路径代替。如果需要在命令里替换真正的 % 字符，那么就双写(%%)。

最简单的有用命令是类似下面的东西

restore_command = 'cp /mnt/server/archivedir/%f %p'这个命令将把以前归档的 WAL 段从 /mnt/server/archivedir 目录拷贝过来。

你当然可以使用某些更复杂的东西，甚至是一个要求操作者挂载合适的磁带的 shell 脚本。

重要的一点是：该命令在失败的时候返回非零值。如果日志文件没有出现在规档中，那么该系统将询问该命令；

在问到的时候，它必须返回非零。这个不是错误条件。还要注意 %p 路径的基础名将和 %f 不一样；不要认为它们是可以互换的。

在归档中找不到的 WAL 段将被认为在 pg_xlog/ 里；这样就允许使用最近没有归档的段。

但是在归档中的段将比 pg_xlog/ 中的优先。在检索归档文件的时候，系统将不会覆盖现有的 pg_xlog/ 内容。

通常，恢复将处理所有可用的 WAL 段，因此将把数据库恢复到当前时间(或者是在所给出的可用 WAL 段数的情况下，

我们能走到的最近的地方)。但是如果你想恢复到某些以前的时刻点(比如，在菜鸟 DBA 删除你的主要事务表之前)，

那么只需要在 recovery.conf 里声明要求的停止点。你可以通过日期/时间来声明，也可以通过特定事务 ID 的结束来声明这个停止点，

我们叫做"恢复目标"。目前，只有日期/时间选项比较有用，因为我们没有工具来帮助你精确地标识应该使用哪个事务 ID

【注意】请注意停止点必须在备份的终止时间之后(也就是 pg_stop_backup 的时间)。

你无法使用一个基础备份恢复到备份正在进行中的某个时刻。要想恢复到该时刻，你必须回到你以前的基础备份，然后从那个位置向前滚动。

如果在恢复过程中发现在 WAL 数据中存在错误，那么恢复将在错误的地方停止，并且不会启动服务器。

在这种情况下，可以指定一个位于错误点之前的"恢复目标"，然后从起始点开始重新运行恢复进程，这样恢复就可以正常完成。

如果由于外部原因(系统崩溃、无法读取 WAL 归档)导致恢复失败，那么可以简单的重新启动恢复过程即可，它将从上次失败的地方继续。

重新启动恢复过程与检查点的操作非常类似：

服务器周期性的强制将其状态记录到磁盘上并更新 pg_control 文件以标识已经处理的 WAL 数据不需要被再次扫描。