转载:原贴 http://bbs.pgsqldb.com/index.php?t=msg&th=6233&start=0&rid=&S=1324a00658e6a322138d2b4e7788678a
PostgreSQL的PITR技术(Point-In-Time-Recovery)
--Seamus Dean 2005-04-11(at PostgreSQL-8.0.2 release)
为什么要写这篇文章?
因为我看了一下,国内所有的PostgreSQL教程都没有很详细的介绍该功能,而相反,国内的Oracle
文章对这块非常的看重。虽然,PostgreSQL的官方文档有一个章节是介绍这块内容的,
但是写得太过‘文学’化。
的确,一个数据库的可靠性和完整性是非常重要的,否则,很难叫人们所接受它。
本文假设读者对PostgreSQL已经有基本的认识,如果你对PostgreSQL还完全不熟悉的话,建议你先
去http://www.postgresql.org看看它的Documentation.
作为最强大的开源数据库,PostgreSQL拥有一切商业数据库所拥有的功能,甚至比商业数据库更好。
在以前的版本中,它在数据恢复,可靠性方面做的不太好,但经过最近几年的发展,已经可以和Oracle
媲美了。
在PostgreSQL7的时候就引入了WAL(Write Ahead Logging)的概念,即预写日志,所有对数据库的更改,
在更改之前必须写到该LOG中,这样,就算机器断电,PostgreSQL也可以从该LOG中知道数据库在断电前做
了什么操作,已经做到第几步了,这样保证了所有事务的完整性,但PostgreSQL7没有提供很好的灾难恢复
机制,一旦数据库崩溃,除非你曾经对数据库作过pg_dump或者file system level backup,否则,你的数据
将全部丢失,并且,就算你曾经对数据库做过备份,也只能恢复到你备份的那一刻的数据,这对一个生产数据库
(特别是24*7生产库)来说,是无法容忍的。
PostgreSQL8的推出,使PostgreSQL的稳定性和可靠性又迈出了划时代的一步。
除了提供对tablespace的支持外,PostgreSQL8提供了支持时间点的恢复---PITR.
其基本原理和Oracle的热备份完全一样:
首先,对数据库在file system level做一个backup(PostgreSQL是首先用pg_start_backup('label')命令,
然后用tar直接tar整个data目录,假设命名为base.tar,然后pg_stop_backup();结束热备。
Oracle首先是用alter tablespace xxx begin backup,然后直接cp数据文件);
然后,备份相关的配置文件(PostgreSQL只需备份postgresql.conf,pg_hba.conf,pg_ident.conf就可以了,其实,
前面的tar已经将这些文件备份了,Oracle需要alter database backup control file......);
最后,备份WAL(
可以设置postgresql.conf中的archive_command,
该命令可以让PostgreSQL8自动将需要的归档的日志文件备份的其他地方中。
但是注意:如果你是让PostgreSQL8调用archive_command来备份WAL的话,
可能根本就做不到PITR,我做过实验,如果依靠base.tar和archive_command产生的WAL其实只能恢复到最后一个
archive_command保存的WAL的数据,pg_xlog/下面可能还有数据,如果PostgreSQL8的数据目录彻底损坏的话,还是会
丢失数据,所以,我建议,在写数据备份脚本的时候,最好将pg_xlog/下面的WAL也一起备份,见下面的cpArch.sh。
)。
如果数据库崩溃,我们就可以使用热备产生的base.tar和archive_command产生的WAL和我们自己备份的WAL(pg_xlog)来进行数据库的
recovery.
下面举例来说明:
我的PostgreSQL运行在:/home/pgsql/下面
数据目录在:/home/pgsql/database/
将热备数据文件备份到/disk3/PostgreSQL/base/下面
将WAL备份到/disk3/PostgreSQL/archives/下面
postgresql.conf中定义了如下的archive_command:
archive_command = 'cp -f %p /disk3/PostgreSQL/archives/%f'
该命令会将PostgreSQL产生的WAL cp到/disk3/PostgreSQL/archives/中。
我的热备脚本如下:
(1)为了使丢失的数据在一分钟之内,在crontab中每分钟将pg_xlog/下面的WAL
backup到/disk3/PostgreSQL/archives/。
crontab:
*/1 * * * * /home/pgsql/bin/cpArch.sh
cpArch.sh:
#!/bin/sh
cp -f /home/pgsql/database/pg_xlog/[0-9]* /disk3/PostgreSQL/archives/
(2)编写热备脚本hotBackup.pl(我用perl):
#!/usr/bin/perl
#############################################################
# hotBackup.pl
# Use to hot backup the PostgreSQL database.
# Author:Seamus Dean
# Date:2005-04-11
##############################################################
my($datadir) ="/home/pgsql/database";
my($bindir) ="/home/pgsql/bin";
my($backupdir) ="/disk3/PostgreSQL/base";
my($receiver) ="ljh13\@sina.com.cn";
sub begin_backup()
{
open(PSQL,"|$bindir/psql") or mail_user("begin backup error.") && exit(100);
print PSQL "select pg_start_backup('backupnow');\n";
close(PSQL);
}
sub end_backup()
{
open(PSQL,"|$bindir/psql") or mail_user("end backup error.") && exit(100);
print PSQL "select pg_end_backup();\n";
close(PSQL);
}
sub do_backup()
{
system("/bin/tar cvf base.tar $datadir");
system("/bin/mv -f base.tar $backupdir/");
}
sub mail_user()
{
my($msg) =@_;
open(MAIL,"|/bin/mail -s backup-result $receiver") or die("can not talk to:mail command.\n");
print MAIL $msg;
close(MAIL);
}
###################################
# tell psql begin our backup
###################################
&begin_backup();
###################################
# do tar
###################################
&do_backup();
####################################
# tell psql end backup
####################################
&end_backup();
####################################
# mail the user about the result
####################################
&mail_user("PostgreSQL backup successfully.");
到这里,备份脚本基本上就完了,你可以将hotBackup.pl放在crontab中周期性的执行。
就算/home/pgsql/database目录彻底崩溃,我们可以像下面这样迅速恢复到1分钟内的数据:
#cp /disk3/PostgreSQL/base/base.tar ./
#tar xvf base.tar
#cd database/
#vi recovery.conf
输入如下内容:
restore_command='cp /disk3/PostgreSQL/archives/%f "%p"'
然后将/home/pgsql/database/pg_xlog/下面的WAL清空。
启动PostgreSQL,我们可以看到如下的LOG信息:
LOG: could not create IPv6 socket: Address family not supported by protocol
LOG: database system was interrupted at 2005-04-11 23:13:28 PDT
LOG: starting archive recovery
LOG: restore_command = "cp /disk3/PostgreSQL/archives/%f "%p""
cp: cannot stat `/disk3/PostgreSQL/archives/00000001.history': No such file or directory
LOG: restored log file "00000001000000000000002E.008EFCAC.backup" from archive
LOG: restored log file "00000001000000000000002E" from archive
LOG: checkpoint record is at 0/2E8EFCAC
LOG: redo record is at 0/2E8EFCAC; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 5271; next OID: 6351357
LOG: automatic recovery in progress
LOG: redo starts at 0/2E8EFCE8
LOG: restored log file "00000001000000000000002F" from archive
LOG: restored log file "000000010000000000000030" from archive
LOG: restored log file "000000010000000000000031" from archive
LOG: restored log file "000000010000000000000032" from archive
LOG: restored log file "000000010000000000000033" from archive
LOG: restored log file "000000010000000000000034" from archive
LOG: restored log file "000000010000000000000035" from archive
LOG: restored log file "000000010000000000000036" from archive
LOG: restored log file "000000010000000000000037" from archive
LOG: restored log file "000000010000000000000038" from archive
LOG: restored log file "000000010000000000000039" from archive
LOG: restored log file "00000001000000000000003A" from archive
LOG: restored log file "00000001000000000000003B" from archive
LOG: restored log file "00000001000000000000003C" from archive
LOG: restored log file "00000001000000000000003D" from archive
LOG: restored log file "00000001000000000000003E" from archive
LOG: restored log file "00000001000000000000003F" from archive
LOG: restored log file "000000010000000000000040" from archive
LOG: restored log file "000000010000000000000041" from archive
LOG: restored log file "000000010000000000000042" from archive
LOG: restored log file "000000010000000000000043" from archive
LOG: restored log file "000000010000000000000044" from archive
LOG: restored log file "000000010000000000000045" from archive
LOG: restored log file "000000010000000000000046" from archive
LOG: restored log file "000000010000000000000047" from archive
LOG: restored log file "000000010000000000000048" from archive
LOG: restored log file "000000010000000000000049" from archive
LOG: restored log file "00000001000000000000004A" from archive
LOG: restored log file "00000001000000000000004B" from archive
LOG: restored log file "00000001000000000000004C" from archive
LOG: record with zero length at 0/4C2BABE4
LOG: redo done at 0/4C2BABA8
LOG: restored log file "00000001000000000000004C" from archive
LOG: archive recovery complete
LOG: database system is ready
显示数据已经成功恢复。
/home/pgsql/database/下面的recovery.conf会变为:recovery.done.
分享到:
相关推荐
### PostgreSQL 双机...通过以上步骤,我们可以有效地实现 PostgreSQL 的双机热备,从而提高系统的可用性和稳定性。此外,还可以进一步优化备份策略,比如增加备份频率、扩展备份存储介质等,以满足不同的业务需求。
总结起来,构建一个PostgreSQL 9.5集群环境,需要综合运用主备复制、双机热备、pgpool负载均衡和故障恢复技术,以及arcsde对空间数据的支持。通过详细规划和精细配置,可以实现高效、稳定且高可用的数据库服务。在...
标题“基于交易日志的数据库同步和热备”涉及到的核心技术是数据库的备份与恢复,特别是利用事务日志实现数据的实时同步。在IT行业中,确保数据的安全性和高可用性至关重要,而数据库同步和热备就是实现这一目标的...
- 对于高可用性和灾难恢复,手册将涵盖逻辑复制、归档日志模式和热备服务器设置。 6. **性能调优** - 查询优化器的工作原理,以及如何通过EXPLAIN和ANALYZE命令分析查询性能。 - 索引设计的最佳实践,包括B树、...
2. **热备复制**:此版本引入了更完善的热备复制功能,允许一个数据库服务器实时复制到另一个服务器,以提高可用性和灾难恢复能力。通过流复制,主服务器会将WAL(Write-Ahead Log)日志发送到备服务器,备服务器...
本书对于如何设置主从复制、热备(Hot Standby)等复制机制都有所介绍,并提供了相应的配置示例和故障排查建议。 故障排查也是数据库管理中不可避免的一个环节,本书用一章节的篇幅来详细讨论了各种故障情况,包括...
PostgreSQL支持多种高可用性解决方案,如流复制(Stream Replication)、热备(Hot Standby)等技术,确保了数据的可靠性和系统的稳定性。这些特性使得PostgreSQL能够在关键业务环境中保持高可用性和数据一致性。 #...
PostgreSQL 提供了多种备份和恢复方式,如物理备份、逻辑备份、流式复制等,确保数据安全。 五、高可用性与故障恢复 8.3 版本支持热备和复制,当主服务器出现问题时,可以无缝切换到备用服务器,确保服务不间断。 ...
本文总结了 PostgreSQL 数据分页技术的概述,介绍了在大数据量时如何高效地使用模糊查询和数据分页浏览,并根据后台设计降低用户界面的使用复杂程度。 一、数据分页浏览技术 数据分页浏览技术是开发中基本都会用到...
### PostgreSQL 9 Administration Cookbook 关键知识点解析 #### 一、PostgreSQL 9 概述与特点 ...通过学习本书,读者可以更好地理解和掌握PostgreSQL数据库的管理和优化技巧,从而有效地应对日常工作中的各种挑战。
【HA for Windows 2003 双机热备...总的来说,HA for Windows 2003双机热备方案通过PlusWell软件提供了全面的故障检测、切换和恢复机制,确保关键业务在任何故障情况下都能持续运行,降低了企业因系统中断带来的风险。
PostgreSQL 9.0 引入了对热备(hot standby)数据库的支持,这是一个重要的里程碑,使得在数据库恢复过程中,standby数据库不仅可以接收并应用Write-Ahead Log (WAL)日志,还能提供只读访问。这种特性在Oracle数据库...
- **新特性介绍**:PostgreSQL 9.0 是一个重要的里程碑版本,它引入了许多新功能,包括支持热备、增强的复制功能(物理复制和流复制)、新的索引类型(如GiST、SP-GiST、GIN和BRIN)等。 - **性能提升**:此版本在...
数据库同步热备解决方案是保障数据安全和业务连续性的重要策略,尤其在大型机构如某大学图书馆这样的信息密集型环境中更是必不可少。这篇博文及其配套的PDF文档可能详细阐述了如何为图书馆的数据库系统建立一个高效...
PostgreSQL 9的standby集群不仅提升了数据安全性和系统可用性,还优化了性能与管理效率,是企业级数据库架构的理想选择。通过详细的配置与操作,构建standby集群成为可能,为企业提供了一个强大的数据管理解决方案。
- **时间线(Timeline)**:用于跟踪数据库的不同历史版本,特别是在进行基于时间点的恢复和备节点晋升为主节点时防止旧 WAL 日志的覆盖。 - **LSN 寻址**:LSN 号用于定位 WAL 记录,通过 pg_current_xlog_insert_...
- **高可用性**:提供了同步/异步复制、延迟备用服务器、级联复制、在线一致物理备份和逻辑备份、PITR(点在时间恢复)以及逻辑复制等特性。 - **其他功能**:支持触发器、函数/存储过程以及多种自定义存储程序语言...
在源码层面,这些操作涉及到的函数如`start_postmaster`、`proc_exit`、`signal`处理函数`reaper`、`AddToDataDirLockFile`以及信号处理函数`sighandler`等,它们共同协作完成PostgreSQL服务器的启动和状态检查。...