目录
环境
文档用途
详细信息
环境
系统平台:N/A
版本:8.4,9.4,10.4
文档用途
本文旨在用于指导基于时间点的恢复,也包括一些用于恢复的一些必要配置。可以用于数据误删,表误删误truncate等一系列误操作带来的数据丢失的恢复。
详细信息
开始前的操作。
1.为Linux上的PostgreSQL安装设置两个环境变量,
|
PITR方法使用连续归档,在$PGDATA/pg_xlog目录使用WAL记录所有数据库更改。因此,在备份时,我们需要执行数据目录的完整备份以及归档的WAL文件,这有助于将数据库恢复到服务器崩溃之前的最后一点。
通过修改PostgreSQL配置文件来启用archive_mode。
|
在上面的命令中,归档目录设置为/var/backup/postgres/archivedir/
如欲通过WAL文件来执行恢复,那么数据库的完整备份是必要条件。
在psql中执行:
|
PostgreSQL执行检查点并将WAL文件的当前位置写入$PGDATA/backup_label。有了这些信息,PostgreSQL会跟踪完整备份的开始时间。当PostgreSQL将仍在内存中的所有已提交的事务刷新到磁盘后,将执行检查点操作。
下面将$PGDATA目录tar到备份位置。
|
tar完数据库后在psql中执行:
|
这将完成完整的在线备份,切换到下一个WAL段并在$PGDATA/pg_xlog目录中创建文件TTTTTTTTSSSSSSSSSSSSSSS.OOOOOOOO.backup并切换到下一个WAL日志。
T的部分用于时间线,S的部分用于段。
现在已经具有完整的数据库备份,可以做一个时间点恢复。
温馨提醒:
有时候人们会错误地使用当前数据库和之前的一组WAL进行PITR。这是不可能的,因为当前数据库已经是最新的,PostgreSQL无法在最新的数据库上重放WAL。所以我们需要一个数据库备份,从中可以前滚所有存档的WAL文件。
首先创建一个表,并在上次完全备份后插入值。
|
输出如下:
|
插入后的时间戳。
|
现在删除表:
|
在此状态下,表将从当前数据库中删除。但插入的值仍存在于存档日志中。
在创建表之前先将数据库回滚到时间点。然后重新应用所有归档的日志,直到我们放弃表格t之前的时间点。我们需要停止数据库并将所有WAL复制到存档目录。这是为了防止PostgreSQL没有归档它们。
|
现在删除$PGDATA,untar以恢复以前的完整数据库备份,并删除$PGDATA/pg_xlog中所有以前的WAL内容。我们不需要以前的数据库备份中的这些WAL文件。
注意:生产数据库不要删除$PGDATA,可以修改$PGDATA,也可以换一台机器操作,千万不要操作错数据库。
|