PostgreSQL基于时间点恢复(PITR)

数据库的PITR是通常数据库都必须知足的技术。其原理是依据以前的物理备份文件加上wal的预写日志模式备份作的恢复。该技术支持8.*及以上版本。下面主要概述PITR的准备和恢复过程。 测试环境
OS 环境:CentOS 6.2
数据库 :PostgreSQL 9.1.3
pg_home=/home/postgres/
pg_data=/database/pgdata/

1、前期工做既要恢复,确定是须要一个备份基础的,不然再怎么的巧妇也难为无米之炊。
1.修改数据库参数,修改postgresql.conf: sql

archive_mode = on
archive_timeout = 300   --单位是秒,此处以5分钟为限强制归档,仅做测试
archive_command = 'cp -i %p /home/postgres/archive/%f'
wal_level = archive

修改完重启下reload,DB

2.基于文件级别的持续备份,
a.基础备份
postgres=# select pg_start_backup('backup_2012_05_20_14:22:10');

b.打包备份pg_data
# cd /database
# tar -cvzf pgdata.tar ./pgdata

c.结束基础备份并切换归档 数据库

postgres=# select pg_stop_backup();

postgres=# select pg_switch_xlog();
 pg_switch_xlog 
----------------
 0/C000020
(1 row)

postgres=# select pg_current_xlog_location();
 pg_current_xlog_location 
--------------------------
 0/C000020
(1 row)

postgres=# create table test_1(id int,name varchar(50));
postgres=# insert into test_1 values (1,'kenyon');
INSERT 0 1

此时在pg_data路径下会产生一个label,能够查看内容有checkpoint时间,基础备份的开始和结束时间,以及标签名称等。由于以前已经设置了archive的三个参数,能够在archive的备份路径pg_home/archive下看到归档的文件会定时传过来。

2、恢复过程
停数据库
# pg_stop

假定数据库的崩溃场景,将pgdata数据删除
# rm -rf /database/pgdata

恢复以前备份的tar文件
# tar xvf pgdata.tar

删除pg_xlog文件夹并重建
# rm -rf pg_xlog # mkdir -p pg_xlog/archive_status

拷贝recovery.conf文件并修改
# cp $PG_HOME/recovery.conf.sample /database/pgdata/
# vi /database/pgdata/recovery.conf
--新增内容,指定恢复文件和路径,%f,%p见上面说明
restore_command = 'cp /home/postgres/archive/%f "%p"'

启动数据库 post

# pg_start
[postgres@localhost archive]$ psql
spsql (9.1.3)
Type "help" for help.

postgres=# select * from test_1;
 id |  name  
----+--------
  1 | kenyon
(1 rows)
--恢复成功,会恢复到以前接收到的最后一个归档文件。另外recovery.conf会更名变成recovery.done

日志内容:
LOG:  shutting down
LOG:  database system is shut down
LOG:  database system was interrupted; last known up at 2012-05-20 22:23:15 CST
LOG:  starting archive recovery
LOG:  restored log file "000000010000000000000002" from archive
LOG:  redo starts at 0/8000078
LOG:  consistent recovery state reached at 0/C000000
LOG:  restored log file "000000010000000000000003" from archive
LOG:  restored log file "000000010000000000000004" from archive
LOG:  restored log file "000000010000000000000005" from archive
LOG:  restored log file "000000010000000000000006" from archive
LOG:  restored log file "000000010000000000000007" from archive
cp: cannot stat `/home/postgres/archive/000000010000000000000008': No such file or directory
LOG:  could not open file "pg_xlog/000000010000000000000008" (log file 0, segment 8): No such file or directory
LOG:  redo done at 0/1C000078
LOG:  last completed transaction was at log time 2012-05-20 23:01:22.960591+08
LOG:  restored log file "000000010000000000000007" from archive
cp: cannot stat `/home/postgres/archive/00000002.history': No such file or directory
LOG:  selected new timeline ID: 2
cp: cannot stat `/home/postgres/archive/00000001.history': No such file or directory
LOG:  archive recovery complete
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

PS:若要恢复到指定时间,还须要再recovery.conf中设置recovrey_target_time,recovery_target_timeline等参数 测试

总结:pitr技术对于7*24小时支撑是相当重要的,可是若是数据库很是小,增大pg_dump备份的频率可能更方便,但对于大数据库就须要了。 大数据

相关文章
相关标签/搜索