我目前有1个主服务器（a）和3个复制服务器（b，c，d）直接来自主服务器，我使用的archive_command是以下脚本： https ： //gist.github.com/Geesu/8640616
所有的服务器都运行PostgreSQL 9.2.6的Ubuntu 12.04.4
这里是每个复制服务器的recovery.conf： https ： //gist.github.com/Geesu/8640635
奇怪的是，在我开始复制服务器大概6个小时之后，其中2个立即落后了，现在正在努力赶上，但是他们不断进一步落后。 这是他们与主人相比有多远：
a 20287.825072 b 2.521136 c 19994.51653 有没有人有任何想法，为什么其中一个服务器几乎完全赶上，但其他人一直落后？ 我已经validation了a和c正在处理WAL段，但它不能够足够快地完成。
a和c的一些日志示例：
cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E0000009A': No such file or directory 2014-01-26 23:02:14 GMT LOG: record with zero length at 109E/9AE622D8 cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E0000009A': No such file or directory 2014-01-26 23:02:14 GMT LOG: streaming replication successfully connected to primary 2014-01-26 23:03:36 GMT FATAL: could not receive data from WAL stream: SSL error: sslv3 alert unexpected message cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E000000B9': No such file or directory 2014-01-26 23:03:41 GMT LOG: record with zero length at 109E/B9E797E0 cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E000000B9': No such file or directory 2014-01-26 23:03:41 GMT LOG: streaming replication successfully connected to primary
也许这是相关的？ 最终它会得到适当的WAL段并进行处理。
任何build议，我可以进一步debugging呢？
这里有一些错误。
首先，您的主服务器正在尝试将WAL压缩文件推送到每个副本，并且只有在三个文件都接收到的情况下才将archive_command视为成功。 这意味着如果一个人死亡，另外两个人将停止接收新的WAL，因为主人的Pg会停留在一遍又一遍地重试同一个段。
你的脚本实际上并没有返回$FAIL ，所以实际上这是行不通的 – 即使所有三个服务器都没有收到WAL文件，它也会报告成功。 它将继续向WAL文件进行压缩，忽略事先的失败意味着整个序列是无用的，不能重播。 这可以很好地解释为什么副本无法find本地的WAL段; 他们可能由于env-var问题（ RSYNC_RSH ），已知主机问题，ssh密钥问题等而无法复制。
我强烈build议您切换到推/拉模式。 让主服务器将 WAL 推送到可靠的存储位置。 然后从该位置获取副本。 主人只需要复制一次文件，而不必担心在不同的服务器上重试不同的服务器，如果有些服务器出现故障，还有一些服务器正在赶上等等。一个越来越stream行的select是Amazon S3，尽pipeWindows Azure块服务（WABS）和OpenStack的Swift也很有用。 一个有用的工具是WAL-E ，它可以作为你的archive_command和restore_command ; 它支持所有的上市商店。
有意思的是，如果你使用S3，你可以有一个存档策略，把旧的东西保存在冰川中，而不是删除它，然后删除它。 这是一个便宜而方便的方式来存储这样的“以防万一” – 但请记住，除非您保存关联的基本备份，否则它是无用的！
如果您必须让主控人员推送到所有三个后端，那么您需要更聪明一点，使用一个脚本来分别跟踪哪些服务器接收到每个WAL段，并在一台服务器接收到一个段时报告成功，所有以前的部分 。 您将需要一个后台作业，不断重试后面的服务器。 即使如此，这是一个坏主意， 它会使你的WAL归档速度慢到最慢的服务器，这实际上是不理想的，可以让主人填满非常糟糕。 我相信这可以起作用，但海事组织太脆弱和复杂。
在您的日志中：
2014-01-26 23:03:36 GMT致命：无法接收来自WALstream的数据：SSL错误：sslv3警报意外消息
您的服务器设置为stream式复制，但他们有SSL问题。 这是sslv3重新协商问题的签名错误，以及早期的脑死亡OpenSSL“修复”它。 确保你已经更新到最新的OpenSSL补丁版本，因为这应该可以解决这个问题。
如果不行，作为解决方法，您可以在postgresql.conf尝试ssl_renegotiation_limit=0 。 看到这个启动板的错误 。