3.4 重放事务日志

一旦我们创建了一个我们自己的初始基础备份，我们可以收集数据库创建的XLOG。当时间到时，我们可以使用所有这些XLOG 文件并执行我们所期望的恢复进程。这就像本节描述的一样工作。

执行基本恢复

在PostgreSQL中，整个恢复过程有一个称为recover.conf的文件管理，其主要驻留在基础备份的主目录中。在启动的时候被读取，并告诉数据库服务器到哪里可以找到XLOG归档，什么时候终止重放，等等。

为了让您开始恢复，我们决定为执行一个基本的备份过程包含一个简单的recovery.conf示例文件：

restore_command = 'cp /archive/%f %p'

recovery_target_time = '2013-10-10 13:43:12'

restore_command 基本上是与您之前见过的archive_command命令相对应的命令。archive_command应该将数据放入归档，restore_command 应该使用一个一个文件为恢复实例提供数据。再次，它是一个简单的提供一个又一个XLOG块的shell命令或者一个简单的shell脚本。您在这里的选项仅仅受限于想象力；PostgreSQL要做的是检查您写的代码的返回码，并通过您的脚本提供的数据。

就像在postgresql.conf中，我们使用%p 和%f作为占位符；这两个占位符的意思和之前的完全一样。

要告诉系统什么时候停止恢复，我们可以设置recovery_target_time。该变量是可选的。如果它没有被指定，PostgreSQL 将一直恢复，直到它运行完 XLOG。在许多情况下，简单地消耗整个XLOG是一个非常可取的过程；如果有东西出现故障，您要恢复尽可能多的数据。但是，并非总是如此。如果您要使PostgreSQL在一个特定的时间带您停止恢复，您必须要把关键的日志放到这里。这里至关重要的部分其实是，要知道您要多大程度地重放XLOG；在一个实际的工作场景，这已经被证明是要回答的很棘手的问题。

[如果您在未来碰巧有一个recovery_target_time，不要担心，PostgreSQL将在您的XLOG中最近的可用事务处开始，并简单地停止恢复。数据库实例将仍然是一致的，并准备采取行动。您不能终止PostgreSQL，但是，在数据丢失的情况您可能会终止您的应用程序，因为缺少XLOG。]

在启动 PostgreSQL之前，您必须对包含基础备份的目录执行 chmod 700，否则，PostgreSQL将输出错误：

iMac:target_directoryhs$ pg_ctl -D /target_directory\

start

server starting

FATAL: data directory "/target_directory" has group or world access

DETAIL: Permissions should be u=rwx (0700).

这种额外的安全检查应该确保您的数据目录不能被某些用户意外读取。因此，从安全的角度来考虑，一个明确的权限更改绝对是一个优势(有备无患)。

既然所有的工作都已经就绪，我们可以通过启动PostgreSQL来启动重放进程：

iMac:target_directoryhs$ pg_ctl –D /target_directory \

start

server starting

LOG: database system was interrupted; last known up at 2013-03-10

18:04:29 CET

LOG: creating missing WAL directory "pg_xlog/archive_status"

LOG: starting point-in-time recovery to 2013-10-10 13:43:12+02

LOG: restored log file "000000010000000000000006" from archive

LOG: redo starts at 0/6000020

LOG: consistent recovery state reached at 0/60000B8

LOG: restored log file "000000010000000000000007" from archive

LOG: restored log file "000000010000000000000008" from archive

LOG: restored log file "000000010000000000000009" from archive

LOG: restored log file "00000001000000000000000A" from archive

cp: /tmp/archive/00000001000000000000000B: No such file or

directory

LOG: could not open file "pg_xlog/00000001000000000000000B" (log

file 0, segment 11): No such file or directory

LOG: redo done at 0/AD5CE40

LOG: last completed transaction was at log time 2013-03-10

18:05:33.852992+01

LOG: restored log file "00000001000000000000000A" from archive

cp: /tmp/archive/00000002.history: No such file or directory

LOG: selected new timeline ID: 2

cp: /tmp/archive/00000001.history: No such file or directory

LOG: archive recovery complete

LOG: database system is ready to accept connections

LOG: autovacuum launcher started

数据库产生的日志的量告诉我们，我们需要知道的关于恢复进程的所有事情，这是绝对值得详细调查的信息。

第一行表明，PostgreSQL已经发现它已经被终止了，并且它必须重新启动。从数据库实例的角度来看，基础备份看起来或多或少像一个立即需要通过重放XLOG来照顾的崩溃；这正是我们想要的。

接下来几行(恢复日志文件…)表明，我们正在一个一个地重放由基础备份创建的XLOG文件。值得一提的是，重放进程于第六个文件处开始启动。基础备份知道从哪里启动，因此，PostgreSQL将自动寻找合适的XLOG文件。

PostgreSQL到达第六个文件(consistent recovery state reached at 0/60000B8)之后显示的信息是非常之重要的。PostgreSQL表明，它已经到达一致状态。这是很重要的。其原因是，基础备份中的数据文件实际上被明确中断(这里请参阅我们前面关于XLOG的章节)，但是数据文件不是被损坏的无法修复。只要我们有足够多的XLOG来恢复，我们就没有问题。如果您不能达到一致的状态，您的数据库实例将不可用，在不提供额外的XLOG的情况下，您的恢复不能工作。

[实事求是的讲，不能达到一致的状态通常表示您的归档进程和您系统设置有问题。到现在为止，如果一切事情都正常工作，没有理由不达到一致状态。]

一旦我们达到一致的状态，一个又一个的文件将被成功重放，直到系统最终查找00000001000000000000000B文件。问题是，该文件没有被源数据库实例创建。逻辑上，将会弹出一个错误。

[没有找到最后一个文件是完全正常的；如果在到达XLOG流的末尾之前，recovery_target_time不让PostgreSQL停止恢复这种类型的错误在意料之中的。不要担心，您的系统其实很好。在错误消息之前，您已经成功地重放了出现的文件的所有东西。]

一旦所有的XLOG都被消耗，并且在前面已经讨论了错误消息，PostgreSQL报告最后一个能够或者应该重放的事务，并启动。现在您有一个完全的恢复数据库实例，您可以立即连接到数据库。一旦恢复结束，PostgreSQL将把recovery.conf重命名为recovery.done，以确保当稍后某个时间点重新启动新的实例时，没有任何伤害。

在XLOG中更先进的定位

到现在为止，我们已经使用16MB的事务日志块恢复了一个数据库到最新可用的时间。我们也看到，您可以定义期望的恢复时间戳。但现在的问题是：您怎么知道到哪个时间点来执行恢复？试想，某人在白天删除了一个表。要是您不能轻易确定恢复时间戳会怎么样呢？要是您要恢复到一个特定的事务将会怎样呢？

recovery.conf 中有所有您所需要。如果您要重放，直到一个特定的事务，您可以参考 recovery_target_xid.。只需指定您所需要的事务并配置 recovery_target_inclusive 来包括这个非常特别的事务或者不配置。如前面所提到的，技术地使用这个设置是相当容易的，目前为止，找到正确的位置来重放是不容易的。

在典型的设置中，找到一个合理的终止恢复的点的最好的方法是使用pause_at_recovery_target。如果它被设置为ture，达到恢复点时，PostgreSQL将不会自动转变为生产实例。相反，他将等待数据库管理员的指令。如果您不知道要重放到什么位置，这是非常有用的。您可以重放，登录，看看到数据库的哪个位置，更改为下一个目标时间，并不断以小步长来重放。

[您必须在postgresql.conf中设置hot_standby = on 以允许在恢复中读取。]

在通过调用一个简单的SQL语句：SELECT pg_xlog_replay_resume()来终止PostgreSQL之后回到恢复。它将使实例移动到您在recovery.conf中设置的下一个位置。一旦您找到了正确的位置，您可以设置pause_at_recovery_target 为false，并调用pg_xlog_replay_resume。或者，您可以简单地使用pg_ctl –D ... promote来停止恢复，并使实例工作。

这个解释太复杂了吗 ？让我们把它列成一个清单：

• 把 restore_command 添加到 recovery.conf 文件。

• 把 recovery_target_time 添加到 recovery.conf 文件。

•在 recovery.conf 文件中，设置 pause_at_recovery_target 为 true。

•在 postgresql.conf 文件中，设置 hot_standby 为 on。

• 启动恢复实例。

• 一旦达到了一致的状态，并且停止恢复，就立即连接到实例。

• 检查您是否已经处于您要去的地方了。

• 如果您不在:

° 更改 recovery_target_time。

° 运行SELECT pg_xlog_replay_resume()。

° 如果需要的话，在检查一遍并重复这段。

[请记住，一旦恢复完成，一旦PostgreSQL作为一个正常的数据库实例启动，稍后(如 9.2)就不能重放XLOG。不采用这个过程，您当然可以直接使用文件系统快照。文件系统快照将始终与PostgreSQL一起工作，因为当您重新启动一个快照数据库实例，它会简单地认为，它 之前已经崩溃，并且正常恢复。]

中途清理XLOG

一旦您配置了归档，您必须存储由源服务器创建的XLOG。从逻辑上讲，这是永远都不可能发生的。有些时候，您必须摆脱这些XLOG；对您的文件来说，有一个健全和可持续的清理策略是必须的。

但是，请记住，您必须保持足够的XLOG以便您总是可以从最新的基础备份执行恢复。但是，如果您确定，某个特定的基础备份不再需要了，您可以安全地清理掉所有的比您要保持的基础备份的XLOG还要早的XLOG。

管理员如何找出要删除什么？最简单的方法是看看您的存档目录：

000000010000000000000005

000000010000000000000006

000000010000000000000006.00000020.backup

000000010000000000000007

000000010000000000000008

在列表的中间检查文件名。备份文件已经被基础备份创建了。它包含了一些关于创建基础备份的方式，并告诉系统在哪里继续重放XLOG。如果备份文件属于您需要的最早的基础备份，您可以安全地清除所有低于数字6的XLOG；在这种情况下，5号文件可以被安全地删除。

在我们的例子中，000000010000000000000006.00000020.backup 包含了下面的信息：

START WAL LOCATION: 0/6000020 (file 000000010000000000000006)

STOP WAL LOCATION: 0/60000E0 (file 000000010000000000000006)

CHECKPOINT LOCATION: 0/6000058

BACKUP METHOD: streamed

BACKUP FROM: master

START TIME: 2013-03-10 18:04:29 CET

LABEL: pg_basebackup base backup

STOP TIME: 2013-03-10 18:04:30 CET

.backup 文件也将为您提供相关的信息，如基础备份创建的时间。它是普通文件，因此，对普通用户来说，阅读这些信息应该很容易。作为一种在某一点删除所有XLOG 文件的选择，在重放它们期间清除它们也是可能的。方法之一是在您的restore_command中隐藏一个rm 命令。虽然在技术上是可能的，但这样做并不一定是明智的(如果您想再次恢复怎么办呢？)。

同时，您也可以在您的recovery.conf文件中添加recovery_end_command命令。recovery_end_command的目标是允许您只要恢复结束，就自动触发一些行动。再次，PostgreSQL将调用一个脚本做您要做的事。当数据库声明它自己为主库时，您可以很容易地使用这个设置来清理较早的XLOG。

切换XLOG文件

如果您要做一个基于XLOG文件的恢复，您已经看到了，每个XLOG将被存档为16MB。如果您不设法创造16MB的变化会发生什么呢？如果您是一个小超市，这只会产生每天50笔交易。最后，您的系统将永远不可能填满16MB。

然而，如果您的系统崩溃，潜在的数据丢失可以看作是在您最后没有完成的XLOG文件的数据量。也许这对您不够好。

在源数据库中的一个postgresql.conf的设置可能对这个问题有帮助。

archive_timeout 告诉PostgreSQL至少每X秒创建一个新的XLOG文件。因此，如果您是这个小超市，您可以让数据库每天在您回家之前创建一个新的XLOG文件。在这种情况下，您可以确定，当天的数据将安全地在您的备份设备上。

手动使PostgreSQL切换到下一个XLOG文件也是可能的。服务器提供了一个称为pg_switch_xlog()的过程来做这个工作：

test=# SELECT pg_switch_xlog();

pg_switch_xlog

----------------

0/17C0EF8

(1 row)

当一些重要的修补工作完成时或者您要确保一个特定的数据库安全地存在于您的XLOG归档时，您可能会调用这个过程。

3.5总结

在本章中，您已经学习了即时恢复，这是一个恢复您的PostgreSQL数据库到任何需啊哟的时间的的一种安全，简单的方法。即时恢复将帮助您实现较好的备份策略并且使您的设置更加健壮。

在下一章中，我们将扩展这个话题，并转到异步复制。您将学习如何使用PostgreSQL的事务日志复制整个数据库实例。