4.4 基于流和基于文件的恢复
生活并不总只是黑色或白色；有时也会有一些灰色色调。对于某些情况下，流复制可能恰到好处。在另一些情况下，基于文件复制和PITR是您所需要的。但是也有许多情况下，您既需要流复制，也需要基于文件的复制。一个例子是：当您较长一段时间中断复制，您可能想再次使用归档来重新同步(resync)slave，而不是再次执行完全的基础备份。这也可能是有用的---保留一个归档一段时间以后调查或重放操作。好消息是PostgreSQL允许您混合基于文件和基于流的复制。您没有必要决定基于流的好还是基于文件的好，您可以同时使用两种方式的优势。您该怎么做呢？事实上，您已经看到了所有的步骤；我们只需按照正确的方式把它们放在一起。
为了让这对您来说更容易，我们已经为您编写了一个完整的例子。
4.4.1 master配置
master上，我们在postgresql.conf中使用如下配置：
wal_level = hot_standby
# minimal, archive, or hot_standby
# (change requires restart)
archive_mode = on
# allows archiving to be done
# (change requires restart)
archive_command = 'cp %p /archive/%f'
# command to use to archive a logfile segment
# placeholders: %p = path of file to archive
# %f = file name only
max_wal_senders = 5
# we used five here to have some spare capacity
除此之外，我们必须添加一些配置到pg_hba.conf来允许流机制。下面是一个例子：
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication hs trust
host replication hs 127.0.0.1/32 trust
host replication hs ::1/128 trust
host replication all 192.168.0.0/16 md5
在我们的例子中，我们只是简单地开了一个完整的网络以允许复制(保持例子简单).
一旦我们做了这些改变，我们就可以重新启动master，并做一个如本章前面所做的基础备份。
4.4.2 slave配置
一旦我们配置了master并做了基础备份，我们就可以开始配置我们的slave系统。为了简单起见，我们假设我们只是用一个slave；我们不会级联复制到其他系统。
我们只需要改变slave的postgresql.conf中的一行：
hot_standby = on # to make the slave readable
下一步，我们可以写一个简单的recovery.conf文件，并把它放到主数据目录：
restore_command = 'cp /archive/%f %p'
standby_mode = on
primary_conninfo = ' host=sample.postgresql-support.de port=5432 '
trigger_file = '/tmp/start_me_up.txt'
我们启动slave,会发生如下事情：
1. PostgreSQL 会调用 restore_command 命令来从归档取事务日志。
2.直到归档中没有更多的日志文件才会停止调用restore_command。
3. PostgreSQL 会尝试建立流连接。
4.如果数据存在它将执行流操作。
°如果没有数据存储在, 它将调用 restore_command 命令从归档取事务日志。
° 它将一直执行该操作，直到归档里没有更多的数据。
° 它将再次尝试建立流连接。
只要您需要就可以保持流操作。如果您想把slave转换为master，您可以再次使用pg_ctl promote 或 recovery.conf中定义的 trigger_file。
4.4.3 错误场景
双重策略的最重要的优势是您可以创建一个集群，它提供一个更高的安全级别，而不仅仅是基于流或简单的基于文件的重放。
在本节，我们可以讨论一些在双重策略集群中典型的错误场景。
master和slave之间的网络连接中断
如果网络出现故障，master可能将不能再成功地执行archive_command操作。XLOG文件的历史必须保持继续，因此，为了以后的归档，master必须对那些XLOG文件进行排队。这可能是一个危险的场景，因为如果文件流被永久地中断，您可能用完master上XLOG的空间。
如果流连接失败，PostgreSQL将会尝试通过基于文件的通道来保持同步自身。如果基于文件的通道也失败了，slave将呆在那里等待网络连接回来。一旦网络回来，它将尝试获取XLOG并简单地继续。
[请记住，slave需要不间断的XLOG流；如果没有XLOG文件丢失或如果流连接仍然可以为slave提供slave需要操作的XLOG,,它只能继续重放XLOG。]
重新启动slave
只要归档有XLOG来做slave的备份，重新启动slave将不会有任何伤害，slave将只会再次启动并尝试从任何可用的来源获得XLOG。不会出现崩溃或任何其他这类问题。
重新启动master
如果master重新启动，这种情况同样没有什么可以批判的。slave将会通过流连接通知master找不到了。它会尝试通过两个渠道获取XLOG，但它不会成功，直到master回来。同样没有像崩溃之类的不好的事情 发生。重新启动两个服务器，操作就可以简单地恢复了。
在归档中损坏的XLOG
如果XLOG在归档汇总损坏，我们要区分两种情况：
1. slave正在流传输： 如果流没问题并且是完整的, slave 将不会注意到在归档中有一些XLOG文件在某种程度上被损坏。只要流连接是可用的，slave永远不需要从XLOG文件读取。
2. 如果我们没有使用流，而是从一个文件重放， PostgreSQL 将会检查每条 XLOG 记录并看它的校验和是否正确。如果发生任何错误, slave 将不会继续重放损坏的XLOG。 这将确保不会衍生出来其他问题，没有损坏的XLOG被重放。您的数据库可能是不完整的，但这将是明智的，到出错点都是一致的。
当然，有太多的事情会出错，但是鉴于这些相似的情况，您可以清楚地看到，该设计已经是尽可能的可靠了。