PostgreSQL 时间点恢复
- PostgreSQL“时间点恢复”（PITR）也称为增量数据库备份、在线备份或存档备份。PostgreSQL 服务器记录所有用户的数据修改事务，如插入、更新或删除，并将其写入一个文件，称为预写 (WAL) 日志文件。此机制使用存储在 WAL 文件中的历史记录来执行自上次数据库完整备份以来所做的前滚更改。
- 它是自上次备份以来的最新存档日志的备份，而不是完整的数据库备份。
- 零停机时间 – 增量数据库备份对于关键系统非常重要，因为该系统不能承受哪怕一分钟的停机时间。使用时间点恢复，可以完全消除数据库备份停机时间，因为此机制可以使数据库备份和系统访问同时发生。
- 节省存储大小 ——使用增量数据库备份，我们每天备份自上次备份以来的最新存档日志文件，而不是完整的数据库备份。
PostgreSQL 服务器中的即时恢复（增量备份）。
备份步骤：
- 修改postgresql.conf支持归档日志
- 进行基础备份（完整数据库备份）
- 备份基础备份至远程存储。
- 将 WAL（存档日志文件）备份到远程存储（持续过程）
时间点恢复步骤：
- 从基础备份中提取文件
- 从 pg_xlog 文件夹复制文件
- 创建 recovery.conf 文件
- 开始恢复
1）使用 initdb 创建测试数据库 集群，/usr/local/pgsql/pgDataPITR/ 下的所有数据库文件
-bash-3.2$ pwd/opt/PostgresPlus/9.1AS/bin -bash-3.2$ initdb start -D /u02/data1/ Start the database-bash-3.2$ ./pg_ctl start -D /u02/data1
2）在 Postgresql 配置文件（postgresql.conf）中进行更改 ，我们需要在 postgresql.conf 文件中做一些更改来告诉 PostgreSQL 如何复制或存档从 PostgreSQL 服务器生成的 WAL 文件。
archive directory: -bash-3.2$ mkdir -p /u02/ssslocation/pgpitr/walbkp Backup Data directory(#tar -cvzf u02/ssslocation/pgpitr/databkp/basebkp.tar.gz /u02/data1/): -bash-3.2$ mkdir -p /u02/ssslocation/pgpitr/databkp Modify postgresql.conf -bash-3.2$ vi /u02/data1/postgresql.conf archive_mode = on # allows archiving to be done(change requires restart) archive_command = 'cp %p /u02/ssslocation/pgpitr/walbkp/%f' # command to use to archive a logfile segment wal_level = hot_standby # minimal, archive, or hot_standby
Restart the database: -bash-3.2$ ./pg_ctl stop -D /u02/data1 -m i waiting for server to shut down....LOG: received immediate shutdown request WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. done server stopped -bash-3.2$ ./pg_ctl start -D /u02/data1 server starting LOG: ** EnterpriseDB Dynamic Tuning Agent ******************************************** * System Utilization: 66 % * * Database Version: 9.1.2.2 * * Operating System Version: * * Number of Processors: 0 * * Processor Type: * * Processor Architecture: * * Database Size: 0.1 GB * * RAM: 1.0 GB * * Shared Memory: 1011 MB * * Max DB Connections: 104 * * Autovacuum: on * * Autovacuum Naptime: 60 Secnds * * InfiniteCache: off * * InfiniteCache Servers: 0 * * InfiniteCache Size: 0.000 GB * *********************************************************************** -bash-3.2$ LOG: loaded library "$libdir/dbms_pipe" LOG: loaded library "$libdir/edb_gen" LOG: loaded library "$libdir/plugins/plugin_debugger" LOG: loaded library "$libdir/plugins/plugin_spl_debugger" LOG: database system was interrupted; last known up at 2012-11-14 12:10:38 IST LOG: database system was not properly shut down; automatic recovery in progress LOG: consistent recovery state reached at 0/20FA714 LOG: record with zero length at 0/20FA714 LOG: redo is not required LOG: ** EnterpriseDB Dynamic Tuning Agent ******************************************** * System Utilization: 66 % * * Database Version: 9.1.2.2 * * Operating System Version: * * Number of Processors: 0 * * Processor Type: * * Processor Architecture: * * Database Size: 0.1 GB * * RAM: 1.0 GB * * Shared Memory: 1011 MB * * Max DB Connections: 104 * * Autovacuum: on * * Autovacuum Naptime: 60 Secnds * * InfiniteCache: off * * InfiniteCache Servers: 0 * * InfiniteCache Size: 0.000 GB * **************************************************************************** LOG: autovacuum launcher started LOG: database system is ready to accept connections
3）首先你需要了解PostgreSQL如何处理 日志文件，pg_xlog和归档日志
- pg_xlog 是 PostgreSQL 日志文件文件夹，用于存储所有数据历史记录。它位于 /u02/data1/pg_xlog。
- 当用户插入、更新或删除一条记录时，所有事务历史记录将自动创建或附加到 pg_xlog 文件夹下的文件日志文件。
- 日志文件格式如下 000000010000000000000001 -> 000000100000000000000006
- 每个日志文件可以处理大约16M的数据，当超过此限制时，它会自动创建一个新的日志文件，文件名遵循0-9和AZ
0000000100000000000000001 .. .. 000000010000000000000009 .. .. 00000001000000000000000A .. .. 00000001000000000000000Z
例如，
[root@asmhost pg_xlog]# ls -lsh 总计 33M 17M -rw------- 1 enterprisedb enterprisedb 16M 11月14日 12:28 000000010000000000000002 17M -rw------- 1 enterprisedb enterprisedb 16M 11月9日 14:55 0000000100000000000000003 4.0K drwx------ 2 enterprisedb enterprisedb 4.0K 11月9日 12:20 archive_status
这是我们将用作前滚 PostgreSQL 时间点恢复的日志文件。
在 postgresql.conf 文件中配置 WAL 文件路径：-
-bash-3.2$ ./psql -p 5445 sssdb sssdb=# show archive_command; archive_command ----------------------------------------- cp %p /u02/ssslocation/pgpitr/walbkp/%f (1 row) sssdb=# show archive_mode; archive_mode -------------- on (1 row)
- 这意味着当 pg_xlog 文件夹增长到某个限制时，比如 6 个日志文件每个包含 16M，当 PostgreSQL 尝试插入新的历史记录并检测到 pg_xlog 已满时，它将自动存档最旧的历史日志文件并将其移动到 /u02/ssslocation/pgpitr/walbkp/ 文件夹。
- 我们必须不断地备份这些存档文件（这就是为什么它被称为增量备份）。我们不再需要进行完整的数据库备份，但我们会不断备份那些存档日志文件。
重要日志文件文件夹
[root@asmhost pg_xlog]# pwd /u02/data1/pg_xlog /u02/ssslocation/pgpitr/walbkp/ /u02/ssslocation/pgpitr/databkp
4）数据模拟和备份过程
创建虚拟表和记录 - 我们将在新表中动态记录，1000k 条记录将强制 PostgreSQL 在 pg_xlog 文件夹中创建足够的日志文件，并触发存档过程将日志文件从 /u02/data1/pg_xlog 存档到 /u02/ssslocation/pgpitr/walbkp，每个日志文件包含大约 16M 大小的文件。
sssdb=# create table test_1 as select * from pg_class; SELECT 456 sssdb=# select * from current_timestamp; current_timestamp ---------------------------------- 14-NOV-12 12:36:23.264212 +05:30 (1 row) sssdb=# create table test_2 as select * from pg_description; SELECT 3534 sssdb=# create table test_3 as select * from pg_description; SELECT 3534 sssdb=# create table test_4(id number); CREATE TABLE sssdb=# select * from current_timestamp; current_timestamp ---------------------------------- 14-NOV-12 12:46:00.076725 +05:30 (1 row) sssdb=# insert into test_4 values(generate_series(100000,10000000)); INSERT 0 990000 sssdb=# select * from current_timestamp; current_timestamp ---------------------------------- 14-NOV-12 12:51:42.144344 +05:30 (1 row)
Log files look like following [root@asmhost pg_xlog]# cd /u02/ssslocation/pgpitr/walbkp [root@asmhost walbkp]# ls 000000010000000000000002 00000001000000000000000F 00000001000000000000001C 000000010000000000000003 000000010000000000000010 00000001000000000000001D 000000010000000000000004 000000010000000000000011 00000001000000000000001E 000000010000000000000005 000000010000000000000012 00000001000000000000001F 000000010000000000000006 000000010000000000000013 000000010000000000000020 000000010000000000000007 000000010000000000000014 000000010000000000000021 000000010000000000000008 000000010000000000000015 000000010000000000000022 000000010000000000000009 000000010000000000000016 000000010000000000000023 00000001000000000000000A 000000010000000000000017 000000010000000000000024 00000001000000000000000B 000000010000000000000018 000000010000000000000025 00000001000000000000000C 000000010000000000000019 000000010000000000000026 00000001000000000000000D 00000001000000000000001A 000000010000000000000027 00000001000000000000000E 00000001000000000000001B [root@asmhost walbkp]# pwd /u02/ssslocation/pgpitr/walbkp [root@asmhost walbkp]# ls 000000010000000000000002 00000001000000000000000F 00000001000000000000001C 000000010000000000000003 000000010000000000000010 00000001000000000000001D 000000010000000000000004 000000010000000000000011 00000001000000000000001E 000000010000000000000005 000000010000000000000012 00000001000000000000001F 000000010000000000000006 000000010000000000000013 000000010000000000000020 000000010000000000000007 000000010000000000000014 000000010000000000000021 000000010000000000000008 000000010000000000000015 000000010000000000000022 000000010000000000000009 000000010000000000000016 000000010000000000000023 00000001000000000000000A 000000010000000000000017 000000010000000000000024 00000001000000000000000B 000000010000000000000018 000000010000000000000025 00000001000000000000000C 000000010000000000000019 000000010000000000000026 00000001000000000000000D 00000001000000000000001A 000000010000000000000027 00000001000000000000000E 00000001000000000000001B [root@asmhost walbkp]# cd /u02/data1/pg_xlog [root@asmhost pg_xlog]# pwd /u02/data1/pg_xlog [root@asmhost pg_xlog]# ls 000000010000000000000002 000000010000000000000010 00000001000000000000001E 000000010000000000000003 000000010000000000000011 00000001000000000000001F 000000010000000000000004 000000010000000000000012 000000010000000000000020 000000010000000000000005 000000010000000000000013 000000010000000000000021 000000010000000000000006 000000010000000000000014 000000010000000000000022 000000010000000000000007 000000010000000000000015 000000010000000000000023 000000010000000000000008 000000010000000000000016 000000010000000000000024 000000010000000000000009 000000010000000000000017 000000010000000000000025 00000001000000000000000A 000000010000000000000018 000000010000000000000026 00000001000000000000000B 000000010000000000000019 000000010000000000000027 00000001000000000000000C 00000001000000000000001A 000000010000000000000028 00000001000000000000000D 00000001000000000000001B archive_status 00000001000000000000000E 00000001000000000000001C 00000001000000000000000F 00000001000000000000001D
5）创建完整数据库备份 - 基础备份
sssdb=# select pg_start_backup('Full backup'); pg_start_backup ----------------- 0/29000020 (1 row)
pg_start_backup 用于创建标签，并将其记录到日志文件中。（实际上这是可选的，好习惯）
使用 tar 命令压缩所有 pgDataPITR 文件夹以制作数据库基础备份。
[root@asmhost databkp]# pwd /u02/ssslocation/pgpitr/databkp [root@asmhost databkp]# tar -cvzf basebkp.tar.gz /u02/data1/ #打包整个数据目录，不需要停机 [root@asmhost databkp]# ls basebkp.tar.gz
- basebkp.tar.gz 这是完整的数据库备份（基础备份），包括 Postgresql 配置、系统和所有其他文件和文件夹。
- pg_stop_backup() 也在日志文件中创建一个标签。（实际上这是可选的，好习惯）
sssdb=# select pg_stop_backup(); 注意：pg_stop_backup 完成，所有必需的 WAL 段都已归档 pg_stop_backup ---------------- 0/29000144 (1 行)
6) 准备时间点恢复
pg_start_backup() 和 pg_stop_backup() 备份标签将在 0000000100000000000000029.00000020.backup 文件中创建。在这里创建标签是一个好习惯。
[root@asmhost pg_xlog]# pwd /u02/data1/pg_xlog [root@asmhost pg_xlog]# cat 000000010000000000000029.00000020.backup 开始 WAL 位置：0/29000020 (file 000000010000000000000029) 停止 WAL 位置：0/29000144 (file 0000000100000000000000029) 检查点位置：0/29000050 备份方法：pg_start_backup 开始时间：2012-11-14 12:57:05 IST 标签：完整备份 停止时间： 2012-11-14 13:04:17 IST
[root@asmhost pg_xlog]# ls -l|wc -l 43 [root@asmhost pg_xlog]# cd /u02/ssslocation/pgpitr/walbkp/ [root@asmhost walbkp]# echo *.backup 000000010000000000000029.00000020.backup [root@asmhost walbkp]# cat 000000010000000000000029.00000020.backup START WAL 位置：0/29000020 (file 0000000100000000000000029) STOP WAL 位置：0/29000144 (file 000000010000000000000029） 检查点位置：0/29000050 备份方法：pg_start_backup 开始时间：2012-11-14 12:57:05 IST 标签：完整备份 停止时间：2012-11-14 13:04:17 IST [root@asmhost walbkp]# ls -l|wc -l 42
7）表 test_5、test_6 创建时间通知——准备进行时间点恢复 #创建测试表
sssdb=# create table test_5(id number(8)); CREATE TABLE sssdb=# insert into test_5 values(generate_series(1,1000000)); INSERT 0 1000000 sssdb=# insert into test_5 values(generate_series(1,1000000)); INSERT 0 1000000 sssdb=# select * from current_timestamp; current_timestamp ---------------------------------- 14-NOV-12 13:13:54.047576 +05:30 (1 row)
sssdb=# create table test_6(id number(8)); CREATE TABLE sssdb=# select * from current_timestamp; current_timestamp ---------------------------------- 14-NOV-12 13:14:34.626699 +05:30 (1 row) sssdb=# create table test_7(id number(8)); CREATE TABLE sssdb=# insert into test_6 values(generate_series(1,1000000)); INSERT 0 1000000 sssdb=# insert into test_7 values(generate_series(1,10000000)); INSERT 0 10000000
[root@asmhost walbkp]# pwd /u02/ssslocation/pgpitr/walbkp [root@asmhost walbkp]# ls -l|wc -l 91 [root@asmhost walbkp]# cd /u02/data1/pg_xlog [root@asmhost pg_xlog]# ls -l|wc -l 53
在继续之前，请先研究一下 PostgreSQL 生成的上述事务日志文件移动。我们必须充分了解 PostgreSQL 何时创建新日志文件以及何时将其移动到存档文件夹，不要忘记日志文件格式 :) ~ 花点时间回顾并理解上述日志文件生成顺序
sssdb=# select table_name, status from user_tables; table_name | status ------------+-------- TEST_1 | VALID # created time 14-NOV-12 12:36:23 TEST_2 | VALID # created time 14-NOV-12 12:46:00 TEST_3 | VALID # created time TEST_4 | VALID # created time 14-NOV-12 12:51:42 TEST_5 | VALID # created time 14-NOV-12 13:13:54 TEST_6 | VALID # created time 14-NOV-12 13:14:34 TEST_7 | VALID # created time 14-NOV-12 14:07:40 (7 rows)
8)灾难来袭
我们必须采取一些措施来让我们的 PostgreSQL 服务器瘫痪。
sssdb=# select * from current_timestamp; current_timestamp --------------------------------- 14-NOV-12 14:07:40.00999 +05:30 (1 row) sssdb=# select * from current_timestamp; current_timestamp --------------------------------- 14-NOV-12 14:07:40.00999 +05:30 (1 row)
--Kill the postgresql process [root@asmhost ~]# ps -ef|grep data1 506 6536 1 0 12:28 pts/1 00:00:00 /opt/PostgresPlus/9.1AS/bin/edb-postgres -D /u02/data1 root 9542 6101 0 14:21 pts/3 00:00:00 grep data1 [root@asmhost ~]# kill -9 $(head -1 /u02/data1/postmaster.pid) [root@asmhost ~]# ps -ef|grep data1 root 9680 6101 0 14:24 pts/3 00:00:00 grep data1
9）恢复过程 的步骤 最后我们进入恢复过程，请记住1个文件和2个文件夹
- 基础备份文件 /u02/ssslocation/pgpitr/databkp/basebkp.tar.gz
- 日志文件尚未归档 - /u02/data1/pg_xlog （Pg_xlog 文件夹下的所有文件）
- WALs – /u02/ssslocation/pgpitr/walbkp （文件夹下的所有存档文件在真实环境中可能是远程存储）
步骤1.将data1重命名为olddata1.bad.data，假设data1文件夹中的数据库文件由于我们刚才创建的灾难而损坏，我们需要稍后创建一个新的数据库。
[root@asmhost u02]# mv data1 olddata1.bad.data [root@asmhost u02]# ls admin data lost+found spl_bkp ssslocation sssw.csv tbs1 app olddata1.bad.data oradata sss.csv sssnew.csv tbs [root@asmhost u02]# pwd /u02 [root@asmhost u02]# mkdir data1 [root@asmhost u02]# ls -l|grep data1 drwxr-xr-x 2 root root 4096 Nov 14 14:38 data1 drwx------ 14 enterprisedb enterprisedb 4096 Nov 14 13:04 data1.bad.data --更改所有者权限 [root@asmhost u02]# chown enterprisedb:enterprisedb数据1 / [root@asmhost u02]# ls -l|grep 数据1 drwxr-xr-x 2 enterprisedb enterprisedb 4096 11月14日 14:38 数据1 drwx------ 14 enterprisedb enterprisedb 4096 11月14日 13:04 数据1.bad.dat
step2.解压/提取文件 basebkp.tar，在 下创建一个新的 data1 文件夹，就像我们之前所做的一样。将所有提取的文件从当前位置移动到 /u02/data1
[root@asmhost pgpitr]# pwd /u02/ssslocation/pgpitr [root@asmhost pgpitr]# cd databkp/ [root@asmhost databkp]# ls basebkp.tar.gz [root@asmhost databkp]# mv /u02/data1
步骤3.启动数据库 #直接启动基础备份
-bash-3.2$ ./pg_ctl start -D /u02/data1 pg_ctl: 另一台服务器可能正在运行；尝试启动服务器 无论如何 服务器启动 -bash-3.2$ LOG： ** EnterpriseDB 动态优化代理 ******************************************** * 系统利用率：66% * * 数据库版本：9.1.2.2 * * 操作系统版本： * * 处理器数量：0 * * 处理器类型： * * 处理器架构：* * 数据库大小：0.1 GB * * RAM：1.0 GB * * 共享内存：1011 MB * * 最大 DB 连接数：104 * * 自动清理：开启 * * 自动清理休息时间：60 秒 * * InfiniteCache：关闭 * * InfiniteCache 服务器：0 * * InfiniteCache 大小：0.000 GB * ***************************************************************************** LOG：已加载库“$libdir/dbms_pipe” LOG：已加载库“$libdir/edb_gen” LOG：已加载库“$libdir/plugins/plugin_debugger” 日志：已加载库“$libdir/plugins/plugin_spl_debugger” 日志：** EnterpriseDB 动态优化代理 ******************************************** * 系统利用率：66% * * 数据库版本：9.1.2.2 * * 操作系统版本： * * 处理器数量：0 * * 处理器类型： * * 处理器架构： * * 数据库大小：0.5 GB * * RAM：1.0 GB * * 共享内存：1011 MB * * 最大 DB 连接数：104 * * 自动清理：开启 * * 自动清理休息时间：60 秒 * * InfiniteCache：关闭 * * InfiniteCache 服务器：0 * * InfiniteCache 大小：0.000 GB * ***************************************************************************** LOG：数据库系统已中断；最后一次启动的时间为 2012-11-14 12:57:05 IST LOG：数据库系统未正确关闭；自动恢复正在进行中 LOG：在 0/29000050 达到一致恢复状态 LOG：在 0/29000020 开始重做 LOG：在 0/290000A0 记录长度为零 LOG：在 0/29000050 完成重做 LOG：自动清理启动器已启动 LOG：数据库系统已准备好接受连接
-bash-3.2$ pwd /opt/PostgresPlus/9.1AS/bin -bash-3.2$ ./psql -p 5445 sssdb psql (9.1.2.2) 键入“help”获取帮助 。sssdb=# select * from user_tables; owner | schemaname | table_name | table_space | status --------------+------------+------------+------------+-------- ENTERPRISEDB | PUBLIC | TEST_1 | | VALID ENTERPRISEDB | PUBLIC | TEST_2 | | VALID ENTERPRISEDB | PUBLIC | TEST_3 | | VALID ENTERPRISEDB | PUBLIC | TEST_4 | | VALID (4 行)
直到恢复表 test_4。此 testPITR1 表是在启动基础备份过程之前创建的，因此这是正确的。
步骤 4. 从 pg_xlog 文件夹复制日志文件。灾难发生时，一些日志文件仍位于 pgDataPITR.bad.data pg_xlog 文件夹中（这些日志文件尚未存档），我们需要将日志文件复制回来并尽可能恢复它。
[root@asmhost pg_xlog]# pwd /u02/olddata1.bad.data/pg_xlog [root@asmhost pg_xlog]# cp -R 000* /u02/data1/pg_xlog/
步骤5. 创建一个recovery.conf文件并将其放在/u02/data1/下
vi recovery.conf restore_command = 'cp /u02/ssslocation/pgpitr/walbkp/%f %p' #归档文件复制过来，未归档的wal日志文件前面已经手动复制过来 recovery_target_time = '14-NOV-12 13:14:34'
这是最后的过程，也是最关键的备份过程
- /usr/local/pgsql/pgbackup/wals/ 是我们备份存档日志文件的文件夹
- recovery_target_time 是我们需要恢复到的时间。省略此设置将使 PostgreSQL 尽可能地恢复，它可能会恢复所有更改。
-bash-3.2$ ./pg_ctl stop -D /u02/data1 -mi LOG：收到立即关闭请求 警告：由于另一个服务器进程崩溃而终止连接 详细信息：邮政局长已命令此服务器进程回滚当前事务并退出，因为另一个服务器进程异常退出并可能损坏共享内存。 提示：您稍后应该能够重新连接到数据库并重复您的命令。 等待服务器关闭...完成 服务器已停止 -bash-3.2$ ./pg_ctl start -D /u02/data1 服务器正在启动 -bash-3.2$ LOG： ** EnterpriseDB 动态优化代理 ******************************************** * 系统利用率：66% * * 数据库版本：9.1.2.2 * * 操作系统版本： * * 处理器数量：0 * * 处理器类型： * * 处理器架构： * * 数据库大小：0.1 GB * * RAM：1.0 GB * * 共享内存：1011 MB * * 最大 DB 连接数：104 * * 自动清理：开启 * * 自动清理休息时间：60 秒 * * InfiniteCache：关闭 * * InfiniteCache 服务器：0 * * InfiniteCache 大小：0.000 GB * ************************************************************************************ LOG：已加载库“$libdir/dbms_pipe” 日志：已加载库“$libdir/edb_gen” 日志：已加载库“$libdir/plugins/plugin_debugger” 日志：已加载库“$libdir/plugins/plugin_spl_debugger” 日志：数据库系统已中断；最后一次已知时间为 2012-11-14 14:52:03 IST 日志：** EnterpriseDB 动态优化代理 ******************************************** * 系统利用率：66% * * 数据库版本：9.1.2.2 * * 操作系统版本： * * 处理器数量：0 * * 处理器类型： * * 处理器架构： * * 数据库大小：0.5 GB * * RAM：1.0 GB * * 共享内存：1011 MB * * 最大 DB 连接数：104 * * 自动清理：开启 * * 自动清理时间：60 秒 * * InfiniteCache：关闭 * * InfiniteCache 服务器：0 * * InfiniteCache 大小：0.000 GB * ******************************************************************************** LOG：开始将时间点恢复至 2012-11-14 13:14:34+05:30 LOG：从存档中恢复日志文件“0000000100000000000000029” 日志：主检查点记录中的资源管理器 ID 无效 日志：在 0/29000050 使用上一个检查点记录 日志：在 0/290000A0 达到一致恢复状态 日志：重做从 0/29000020 开始 日志：从存档中还原 了日志文件“00000001000000000000002A” 日志：从存档中还原了日志文件“00000001000000000000002B” 日志：从存档中还原了日志文件“00000001000000000000002C” 日志 ：从存档中还原了日志文件“00000001000000000000002D” 日志：从存档中还原了日志文件“00000001000000000000002E” 日志：还原了日志文件来自存档日志的“00000001000000000000002F” ：来自存档日志的已还原日志文件“000000010000000000000030” ：来自存档日志的已还原日志文件“000000010000000000000031” ：恢复在提交事务 2237 之前停止，时间 2012-11-14 13:14:38.881279+05:30 日志：重做完成于 0/31A76348 日志：最后完成的事务记录时间为 2012-11-14 13:14:17.399818+05:30 cp：无法统计“/u02/ssslocation/pgpitr/walbkp/00000002.history”：没有此文件或目录 LOG：选定的新时间线 ID：2 cp：无法统计“/u02/ssslocation/pgpitr/walbkp/00000001.history”：没有此文件或目录 LOG：存档恢复完成 LOG：数据库系统已准备好接受连接 LOG：自动真空启动器已启动
上述 recovery.conf 文件将使 PostgreSQL 从 /usr/local/pgsql/pgbackup/wals/ 文件夹中获取存档日志文件并恢复截至 2012 年 11 月 14 日 13:14:34 （表 test_6 创建）的数据更改。
-bash-3.2$ ./psql -p 5445 sssdb psql (9.1.2.2) 键入“help”获取帮助 。sssdb=# select * from user_tables; owner | schemaname | table_name | table_space | status --------------+------------+------------+-------------+-------- ENTERPRISEDB | PUBLIC | TEST_1 | | VALID ENTERPRISEDB | PUBLIC | TEST_2 | | VALID ENTERPRISEDB | PUBLIC | TEST_3 | | VALID ENTERPRISEDB | PUBLIC | TEST_4 | | VALID ENTERPRISEDB | PUBLIC | TEST_5 | | VALID ENTERPRISEDB | PUBLIC | TEST_6 | | VALID (6 行)
- 表 testpitr2 已恢复。
- PS恢复过程完成后，PostgreSQL 将把 recovery.conf 重命名为 recovery.done，以避免再次启动恢复过程。
- 我们可以查看pg.log文件来了解PostgreSQL如何处理恢复过程。
- 这是一个一次性过程，恢复过程开始和结束后，我们不能做任何恢复更改（比如前滚到另一个时间）。#详细原理待补充
如果我们想要前滚到另一个恢复时间，我们需要重新启动整个恢复过程，例如从基础备份中提取文件并复制日志文件。这是因为在 PostgreSQL 恢复数据后，所有日志文件格式都将更改为其他格式，如下所示
[root@asmhost data1]# cat recovery.done restore_command = 'cp /u02/ssslocation/pgpitr/walbkp/%f %p' recovery_target_time = '14-NOV-12 13:14:34' [root@asmhost data1]#
- 恢复后日志文件数量将增加
- 00000001 –> 00000002 –> 00000003
- 如果我们想要恢复于 2012 年 11 月 14 日 13:14:34 创建的表 test_6，则无法做到这一点，它会在日志文件中输出错误，除非我们重新启动整个恢复过程。
- 此归档日志文件事务备份和恢复机制在Oracle等许多企业数据库中实现。
