PostgreSQL流与基于文件的复制（就服务器行为和配置而言）

我试图了解PostgreSQL复制的最佳用法及其工作方式，以便在生产环境中进行故障排除。

我很难理解以下两种复制类型之间的区别：（1）配置（2）在每种情况下主/从2个服务器的性能

在PostgreSQL（9.2+）上的复制实际上是在Master上创建大小为16MB的XLOG文件（取决于创建每个文件的频率设置），并通过某种方法发送到Slave。

我的设置（出于这个问题的目的）

在主
archive_command ='rsync -av％p postgres @ [SlaveIP]：[wal_archive_folder] /％f' 上配置Postgresql.conf

从属服务器上配置Recovery.conf以读取日志文件
restore_command ='cp [wal_archive_folder] /％f \“％p \”'
primary_conninfo ='主机= [MasterIP]端口= 5432 user = postgres'

我的问题是，此配置的哪一部分使这种“流式”复制与“日志传送”相比较？我的主服务器配置为使用rsync将日志发送到从服务器（此日志是否发送？）我的从服务器配置为能够在recovery.conf中连接到主服务器（此数据流吗？）

问题的第二部分：发生了什么？我了解PostgreSQL上还有一个通过WAL_sender和WAL_receiver的协议。但是我不清楚这是否仅用于流式传输，如果是，则rsync在主服务器中如何使用？

：） 谢谢！！很抱歉，如果这是一个明显的问题。我一直在阅读大量的博客/书籍，但是很难理解。Postgres Wiki的深度是如此之深，以至于需要花很长时间才能完全理解（我有最后期限）

“流复制”是指通过replication连接上的walsender协议，通过主服务器和副本之间的TCP / IP连接连续发送WAL记录。主服务器从中读取自己的WAL，pg_xlog并根据需要将其发送到副本。它在主服务器上配置了一条primary_conninfo指令recovery.conf和pg_hba.conf条目以允许replication连接。您还需要wal_keep_segments文档中包含的其他选项。

“日志传送”是指通过文件传输协议将WAL记录作为整个WAL存档定期发送到存档位置，副本可以从中获取它们。它在master中的restore_commandin recovery.conf和中配置了指令archive_command。PostgreSQL不在乎文件在哪里或如何传输，仅在archive_command将文件放到那里并restore_command获取所需的归档文件即可。这样就可以构建PgBarman和WAL-E之类的系统。

流复制没有那么多延迟，因为记录是在生成时发送的。但是，它要求主服务器和副本服务器都必须联机并且能够直接通信。它还要求副本保持足够的状态，以使主服务器仍具有副本所需的WAL的磁盘副本，并且通常需要您花费额外的pg_xlog空间来为副本保留额外的WAL。

日志传送复制的延迟更大，因为一旦发送了整个归档文件，该副本仅会看到WAL。但是，即使主服务器和副本服务器无法通过使用共享存储位置直接通过TCP / IP进行通信，它也可以工作。即使副本关闭了一段时间，它也可以继续工作，因为主数据库pg_xlog仅在存档后才丢弃WAL ，因此即使主数据库无法发送WAL，WAL仍在存档中并且可供副本使用通过流式传输。请注意，archive_command永不放弃，因此pg_xlog如果归档失败，可以填满。因此，最好将其存档到可靠的位置，然后再从该位置获取副本服务器。

通常，您实际上将两者结合在一起，即同时使用两者。在这种情况下，一切正常时将使用流复制。如果副本太落后，并且主控已丢弃所需的xlog，出现连接问题等，则副本将切换为读取已归档的WAL，直到被追上。它将定期重试切换回流，直到成功。

如果只使用一种，请使用日志传送，因为没有日志传送回退的流式复制很容易发生（直到PostgreSQL 9.4为止），导致复制滞后，导致失败，从而导致无法重建副本。

PostgreSQL 9.4对此做了些改动，因为流式复制现在可以使用“复制插槽”。这样一来，母版就可以跟踪副本所需的WAL数量，并避免在副本重放之前将其丢弃。因此，wal_keep_segments如果您使用复制插槽（不是默认插槽），则不再需要。

请参阅我的文章PostgreSQL 9.4中的流复制插槽。

9.4还介绍了流逻辑复制的基础，这是又一种机制，旨在供逻辑复制系统（例如Londiste，Slony-I）和新的双向异步多主复制功能使用。