执行完您的第一个即时恢复(PITR,Point-In-Time-Recovery)，我们准备在一个真正的复制设置上工作。在本章，您将学会如何设置异步复制和流。我们的目标是确保您可以实现更高的高可用和更高的数据安全性。
在本章，我们将讨论以下主题：
• 配置异步复制
• 理解流
• 合并流和归档
• 管理时间线
在本章的最后,您将很容易地在几分钟内设置流复制。
4.1 设置流复制
在前面章节中，我们已经从简单的16MB XLOG文件做了恢复。从逻辑上讲，重放进程一次只能重放16MB。这在您的复制设置中会导致延迟，因为您必须等到master数据库实例创建完16MB。在许多情况下，这种延迟是不能被接受的。
[丢掉了最后的XLOG文件，该文件尚未最后确定(并因此不发送归档，由于崩溃丢失)，往往是为什么人们报告在即时恢复(PITR,Point-In-Time-Recovery) 情况下数据丢失的核心原因。]
在这种情况下，流复制将解决您的问题。使用流复制，复制的延迟将是最小的，您可以享受保护您的数据的一些额外的水平。
让我们来谈谈PostgreSQL流基础设施的总体架构。下图显示了基本的系统设计：
您已经看到了这种类型的架构。我们在这里添加了流连接。它基本上是一个正常的数据库连接，和您使用任何其它应用的连接一样。唯一的区别是，在流连接的情况下，该连接处于一种能够携带XLOG的特殊模式。
4.1.1 调整master服务器上的配置文件
现在的问题是：如何才能使一个流连接存在？在前面的例子中已经做了大部分基础设施。在master上，以下设置必须设置：
• wal_level 必须设置为 hot_standby
• max_wal_senders 必须设置为一个合理的较高的值来支持足够多的slaves
[archive_mode和archive_command怎么设置？很多人使用流复制尽可能地使他们的系统复制更多的数据到slave。除此之外，基于文件的复制经常被使用来确保有一个额外的安全层。基本上，两种机制使用相同的技术；在基于流和基于归档的恢复中只是XLOG源不同。]
既然master知道它应该产生足够的XLOG，处理XLOG发送等，我们可以继续下一个步骤。
出于安全的原因，您必须配置master能够流复制连接。这需要改变pg_hba.conf正如前面章节所示。其次，这需要运行pg_basebackup和随后的流连接。如果您正在使用传统的方式做基础备份，您还需要允许复制连接到流式传输XLOG，因此，这一步是必须的。
一旦您的master已经成功地配置了，您可以重新启动数据库(以使wal_level和max_wal_senders工作)并继续在slave上工作。
4.1.2 处理pg_basebackup和recovery.conf
到现在，您已经看到那个进程绝对一致地执行正常的即时恢复(PITR，Point-In-Time-Recovery)。目前唯一不同的是wal_level,为了正常的即时恢复(PITR，Point-In-Time-Recovery)它必须配置不同的参数。这是相同的技术，没有差别。
为了取得基础备份库我们使用pg_basebackup正如前面章节所示。下面是一个例子：
iMac:dbhs$ pg_basebackup -D /target_directory \
-h sample.postgresql-support.de\
--xlog-method=stream
既然我们已经做了一个基础备份，我们现在可以去配置流了。要做到这一点，我们必须写一个叫recovery.conf(就像之前)的文件。下面是一个简单的例子：
standby_mode = on
primary_conninfo= ‘ host=sample.postgresql-support.de port=5432 ‘
我们有两个新的设置：
• standby_mode: 此设置将确保PostgreSQL一旦耗尽XLOG不会停止。相反，它会等待新的XLOG到达。要确保第二个服务器作为standby此设置是必须的,standby持续重放XLOG。
• primary_conninfo: 此设置会告诉我们的slave哪里可以找到master。您必须放置一个标准的 PostgreSQL连接串， (就像在 libpq中) primary_conninfo 作为核心告诉 PostgreSQL 来流传送XLOG。
对于基本的设置，这两个设置完全足够了。现在我们所要做的启动slave，就像您开始启动一个正常的数据库实例。
iMac:slavehs$ pg_ctl -D . start
server starting
LOG: database system was interrupted; last known up
at 2013-03-17 21:08:39 CET
LOG: creating missing WAL directory
"pg_XLOG/archive_status"
LOG: entering standby mode
LOG: streaming replication successfully connected
to primary
LOG: redo starts at 0/2000020
LOG: consistent recovery state reached at 0/3000000
数据库实例已经成功启动了。它检测到正常的操作已经中断。然后它进入standby模式，并开始从primary流传输XLOG。PostgreSQL然后到达一致状态，并且该系统 准备行动。
4.1.3 使slave可读
到目前为止，我们只设置了流传输。slave已经开始消耗来自master的事务日志，但是它还不是可读的。如果您尝试连接到该实例，您将面临如下场景：
iMac:slavehs$ psql -l
FATAL: the database system is starting up
psql: FATAL: the database system is starting up
这是默认配置。slave实例一直是备份模式并保持重放XLOG。
如果您想让slave可读，您必须在slave系统上适配postgresql.conf；hot_standby必须设置为on。您可以直接设置这个，但是您也可以在以后更改，当您需要这个特征的时候，简单地重启slave实例。
iMac:slavehs$ pg_ctl -D . restart
waiting for server to shut down....
LOG: received smart shutdown request
FATAL: terminating walreceiver process due to administrator command
LOG: shutting down
LOG: database system is shut down
done
server stopped
server starting
LOG: database system was shut down in recovery at 2013-03-17 21:56:12
CET
LOG: entering standby mode
LOG: consistent recovery state reached at 0/3000578
LOG: redo starts at 0/30004E0
LOG: record with zero length at 0/3000578
LOG: database system is ready to accept read only connections
LOG: streaming replication successfully connected to primary
重启将关闭服务器，并启动它再次备份。这不是太多的惊喜；然而，这值得看看日志。您可以看到，一个叫walreceiver的进程被终止。
一旦我们做了备份并且运行，我们就可以连接到服务器。从逻辑上讲，我们只允许执行只读操作：
test=# CREATE TABLE x (id int4);
ERROR: cannot execute CREATE TABLE in a read-only transaction
正如预期的结果，服务器将不接受写入。记住，slave是只读的。
4.1.4 底层协议
当使用流复制时，您应该注意两个进程：
• wal_sender
• wal_receiver
wal_sender实例是提供XLOG给他们的slave上称为wal_receiver进程的master实例上的进程。每个slave都有一个wal_receiver进程，并且这个进程恰好连接到数据源的一个wal_sender进程。
整件事情内部是如何工作的呢？正如我们以前所说的，从slave到master的连接基本上是一个 正常的数据库连接。事务日志采用和COPY命令一样的方法。COPY模式内部，PostgreSQL使用微语言来回地传送信息。主要的优势是这种微语言有它自己的解析器，因此快速并且以相当容易，非侵入性的方式增加功能是可能的。到了PostgreSQL9.2,一下命令是支持的：
• IDENTIFY_SYSTEM
• START_REPLICATION <position>
• BASE_BACKUP
°° [LABEL ‘label‘]
°° [PROGRESS]
°° [FAST]
°° [WAL]
°° [NOWAIT]
您所看到的是和pg_basebackup提供的作为命令行标志的协议等级。