本文档为PostgreSQL 9.6.0文档，本转载已得到原译者彭煜玮授权。
1. 归档恢复设置
restore_command (string)
用于获取 WAL 文件系列的一个已归档段的本地 shell 命令。这个参数是归档恢复所必需的，但是对于流复制是可选的。在该字符串中的任何%f会被替换为从归档中获得的文件的名字，并且任何%p会被在服务器上的复制目标路径名替换（该路径名是相对于当前工作目录的，即集簇的数据目录）。任何%r会被包含上一个可用重启点的文件的名字所替换。在那些必须被保留用于使得一次恢复变成可重启的文件中，这个文件是其中最早的一个，因此这个信息可以被用来把归档截断为支持从当前恢复重启所需的最小值。%r通常只被温备配置（见Section 26.2）所使用。要嵌入一个真正的%字符，需要写成%%。
很重要的一点是，该命令只有在成功时才返回一个为零的退出状态。该命令将会被询问不存在于归档中的文件名，当这样被询问时它必须返回非零。例子：
restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows一个例外是如果该命令被一个信号（不是SIGTERM，它是数据库服务器关闭的一部分）或者一个 shell 错误（例如命令未找到）终止，则恢复将会中止并且服务器将不会启动。
archive_cleanup_command (string)
这个可选参数指定了一个 shell 命令，它将在每一个重启点被执行。archive_cleanup_command的目的是提供一种清除不再被后备服务器需要的旧的已归档 WAL 文件的机制。任何%r会被替换为包含最后一个可用重启点的文件的名称。那是使一次恢复变成可重启的所必须被保留的最早的文件，并且因此比%r更早的所有文件可以被安全地移除。这个信息可以被用来把归档截断为支持从当前恢复重启所需的最小值。对于单一后备配置，pg_archivecleanup模块常常被用在archive_cleanup_command中，例如：
archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'但是注意，如果多个后备服务器正在从同一个归档目录中恢复，你将需要保证只有当任意服务器都不再需要 WAL 文件时才会删除它们。archive_cleanup_command通常被用于一种温后备配置（见Section 26.2）中。要在该命令中嵌入一个真正的%字符，需要写成%%。
如果该命令返回一个非零退出状态，则将会写出一个警告日志消息。一个例外是如果该命令被一个信号或者一个 shell 错误（例如命令未找到）终止，则会抛出一个致命错误。
recovery_end_command (string)
这个参数指定了一个将只在恢复末尾被执行一次的 shell 命令。这个参数是可选的。recovery_end_command的目的是为复制或恢复之后的清除提供一种机制。与archive_cleanup_command中相似，任何%r会被替换为包含最后一个可用重启点的文件的名称。
如果该命令返回一个非零退出状态，则一个警告日志消息将被写出并且不管怎样该数据库将继续启动。一个例外是如果该命令被一个信号或者 shell 错误（例如命令未找到）中止，该数据库将不会继续启动。
2. 恢复目标设置
默认情况下，恢复将会一直恢复到 WAL 日志的末尾。下面的参数可以被用来指定一个更早的停止点。在recovery_target、recovery_target_name、recovery_target_time和recovery_target_xid中，最多只能使用一个，如果在配置文件中使用了多个，将使用最后一个。
recovery_target = 'immediate'
这个参数指定恢复应该在达到一个一致状态后尽快结束，即尽早结束。在从一个在线备份中恢复时，这意味着备份结束的那个点。
在技术上，这是一个字符串参数，但是'immediate'是目前唯一允许的值。
recovery_target_name (string)
这个参数指定（pg_create_restore_point()所创建）的已命名的恢复点，恢复将进入该恢复点。
recovery_target_time (timestamp)
这个参数指定恢复将进入的时间戳。
recovery_target_xid (string)
这个参数指定恢复将进入的事务 ID。记住虽然事务 ID 是在事务开始时顺序分配的，但是事务可能以不同的数字顺序完成。那些在指定事务之前（也可以包括该事务）提交的事务将被恢复。精确的停止点也受到recovery_target_inclusive的影响。
下列选项进一步指定恢复目标，并且影响到达目标时会发生什么：
recovery_target_inclusive (boolean)
指定我们是否仅在指定的恢复目标之后停止（true），或者仅在恢复目标之前停止（false）。适用于recovery_target_time或者recovery_target_xid被指定的情况。这个设置分别控制事务是否有准确的目标提交时间或 ID 将被包括在该恢复中。默认值为 true。
recovery_target_timeline (string)
指定恢复到一个特定的时间线中。默认值是沿着基础备份建立时的当前时间线恢复。将这个参数设置为latest会恢复到该归档中能找到的最新的时间线，这在一个后备服务器中有用。除此之外，你只需要在复杂的重恢复情况下设置这个参数，在这种情况下你需要返回到一个状态，该状态本身是在一次时间点恢复之后到达的。
recovery_target_action (enum)
指定在达到恢复目标时服务器应该立刻采取的动作。默认动作是pause，这表示恢复将会被暂停。promote表示恢复处理将会结束并且服务器将开始接受连接。最后，shutdown将在达到恢复目标之后停止服务器。
使用pause设置的目的是：如果这个恢复目标就是恢复最想要的位置，就允许对数据库执行查询。暂停的状态可以使用pg_xlog_replay_resume()（见Table 9-80）继续，这会让恢复终结。如果这个恢复目标不是想要的停止点，那么关闭服务器，将恢复目标设置改为一个稍后的目标并且重启以继续恢复。
要让实例在想要的重放点那里准备好，shutdown设置可以派上用场。该实例将仍能重放更多 WAL 记录（并且事实上将不得不重放从下一次它被启动后最后一个检查点以来的 WAL 记录）。
注意由于在recovery_target_action被设置为shutdown时，recovery.conf将不会被重命名，任何后续的启动都将会以立刻关闭为终结，除非该配置被改变或者recovery.conf文件被手工移除。
如果没有设置恢复目标，这个设置没有效果。如果没有启用hot_standby，pause设置的动作将和shutdown一样。
3. 后备服务器设置
standby_mode (boolean)
指定是否将PostgreSQL服务器作为一个后备服务器启动。如果这个参数为on，当到达已归档 WAL 末尾时该服务器将不会停止恢复，但是将通过使用restore_command获得新的 WAL 段以及/或者通过使用primary_conninfo设置连接到主服务器来尝试继续恢复。
primary_conninfo (string)
指定后备服务器用来连接主服务器的连接字符串。这个字符串的格式在Section 32.1.1中描述。如果在这个字符串中有任何选项未被指定，那么将检查相应的环境变量（见Section 32.14）。如果环境变量也没有被设置，则使用默认值。
连接字符串应当指定主服务器的主机名（或地址），以及端口号（如果它和后备服务器的默认端口不同）。还要指定对应于主服务器上合适权限角色的用户名（见Section 26.2.5.1）。如果主服务器要求口令认证，还需要提供一个口令。它可以在primary_conninfo字符串中提供，或者在后备服务器（使用replication作为数据库名）的一个单独~/.pgpass文件中提供。不要在primary_conninfo字符串中指定一个数据库名。
如果standby_mode为off，这个设置没有效果。
primary_slot_name (string)
有选择地指定通过流复制连接到主服务器时使用一个现有的复制槽来控制上游节点上的资源移除。如果没有设置primary_conninfo则这个设置无效。
trigger_file (string)
指定一个触发器文件，该文件的存在会结束后备机中的恢复。即使这个值没有被设置，你也能够使用pg_ctl promote来提升后备机。如果standby_mode为off，这个设置没有效果。
recovery_min_apply_delay (integer)
某人情况下，一个后备服务器会尽快恢复来自于主服务器的 WAL 记录。有一份数据的延时拷贝是有用的，它能提供机会纠正数据丢失错误。这个参数允许你将恢复延迟一段固定的时间，如果没有指定单位则以毫秒为单位。例如，如果你设置这个参数为5min，对于一个事务提交，只有当后备机上的系统时钟超过主服务器报告的提交时间至少 5分钟时，后备机才会重放该事务。
有可能服务器之间的复制延迟会超过这个参数的值，在这种情况下则不会增加延迟。注意延迟是根据主服务器上写 WAL 的时间戳以及后备机上的当前时间来计算。由于网络延迟或者级联复制配置导致的传输延迟可能会显著地减少实际等待时间。如果主服务器和后备机上的系统时钟不同步，这会导致恢复比预期的更早应用记录。但这不是一个主要问题，因为这个参数有用的设置比服务器之间的典型事件偏差要大得多。
只有在事务提交的 WAL 记录上才会发生延迟。其他记录还是会被尽可能快地重放，这不会成为问题，因为 MVCC 可见性规则确保了在对应的提交记录被应用之前它们的效果不会被看到。
一旦恢复中的数据库已经达到一致状态，延迟就会产生，直到后备机被提升或者触发。在那之后，后备机将会结束恢复并且不再等待。
这个参数的目的是和流复制部署一起使用，但是，如果指定了该参数，所有的情况下都会遵守它。使用这个特性也会让hot_standby_feedback被延迟，这可能导致主服务器的膨胀，两者一起使用时要小心。
Warning
当synchronous_commit被设置为remote_apply时，同步复制会受到这个设置的影响，每一个COMMIT都需要等待被应用。
