Postgres 复制落后 - master -> slave, slave, slave

Question

我目前有 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

有没有人知道为什么其中一台服务器几乎完全赶上，而其他服务器却一直落后？我已经验证 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 段并进行处理。

关于如何进一步调试的任何建议？

Answer 1

这里有一些问题。

沃尔玛脚本

尝试推送到每个服务器，直到全部成功

首先，您的主服务器正在（或正在尝试）将 WAL 存档推送到每个副本，并且仅当所有三个副本都收到该文件时才将 archive_command 视为成功。这意味着如果其中一个发生故障，另外两个将停止接收新的 WAL，因为主服务器上的 Pg 将一直卡住，一遍又一遍地重试同一段。

失败时没有注意到

您的脚本无法实际返回$FAIL，因此实际上这不起作用 - 即使所有三个服务器都无法接收 WAL 文件，它也会报告成功。它将继续缓慢地写入 WAL 文件，忽略先前的失败意味着整个序列无用且无法重播的事实。这可以很好地解释为什么副本无法​​找到本地 WAL 段；它们可能由于环境变量问题 ( RSYNC_RSH)、已知主机问题、ssh 密钥问题等而无法复制。

如何修复 wal 发送脚本

我强烈建议您切换到推/拉模型。让主服务器将WAL推送到可靠的存储位置。然后从该位置提取副本。主服务器只需复制文件一次，并且不必担心在某些服务器出现故障、其他服务器正在恢复等情况下在不同点重试不同的服务器。对此越来越流行的选择是 Amazon S3，尽管 Windows Azure块服务 (WABS) 和 OpenStack 的 Swift 也很有用。WAL-E是一个有用的工具，它可以用作您的archive_command和restore_command；它支持所有列出的商店。

方便的是，如果您使用 S3，您可以制定一个存档策略，将旧内容存储在 Glacier 中，而不是删除它，然后稍后再将其删除。这是一种便宜且方便的方式来存储此类内容“以防万一” - 但请记住，除非您也存储关联的基本备份，否则它是没有用的！

如果您必须将主控推送到所有三个后端，那么您需要对此更加聪明，使用一个脚本来单独跟踪哪些服务器已收到每个 WAL 段，并在一台服务器收到一个段时报告成功，并且之前的所有片段。您需要一个后台作业来不断重试落后的服务器。即便如此，这也是一个坏主意。它会让你的 WAL 归档像最慢的服务器一样慢，这确实不理想，并且可能会让主服务器严重填满。我确信这可以发挥作用，但在我看来，它太脆弱和复杂了。

流复制被破坏 - SSLv3 重新协商错误？

在你的日志中：

2014-01-26 23:03:36 GMT 致命：无法从 WAL 流接收数据：SSL 错误：sslv3 警报意外消息

您的服务器已设置为流式复制，但存在 SSL 问题。这就是sslv3重新协商问题的签名错误，早期脑死亡的OpenSSL对此进行了“修复”。确保您已更新到最新的 OpenSSL 补丁版本，因为这应该可以解决问题。

如果没有，作为解决方法，您可以尝试ssl_renegotiation_limit=0使用postgresql.conf. 请参阅此启动板错误。