我们目前正在运行主 -> 从、从、从、从，使用 postgresql 9.2.8 设置，并使用流式传输和 WAL-E/S3 来处理 wal 段。
所有副本当前是否都处于“恢复中”？对所有副本运行 SELECT pg_is_in_recovery(); 均返回 true，这令人担忧。我们可以对它们运行查询（假设它们不超过 30 秒）。
我正在尝试使用 WAL-E 从现有从属服务器之一启动另一个副本，但由于每个副本都处于恢复模式，我目前无法这样做。我无法在副本上运行 pg_basebackup 或使用 wal-e 的备份功能。
Amy 我是不是忽略了某些显而易见的事情？我唯一能想到的就是大约 2 个月前我们遇到了一个问题，我们的主服务器上的硬盘满了，然后它就关闭了。我们能够启动它，清理磁盘空间，然后继续从主服务器进行流式传输/复制。
如果我只需启动 3 个 postgresql 服务器并使用流式传输/存档将它们配置为 3 个服务器链（主服务器 -> 从服务器 -> 从服务器），它就可以与 WAL-E 正常工作，因为我已经这样做了。只是出于某种原因，我无法让现有的生产副本流式传输/存档到任何其他服务器。具体来说，archive_command 永远不会在任何副本上运行（因为它卡在恢复模式）。
有人对我如何进一步调试/诊断这个问题有什么建议吗？我正在尝试寻找一种解决方案，而不会对我们的生产数据库造成重大停机（因为我总是可以将数据库重新导入到新服务器并重新启动链，但这需要 12 多个小时）。
以下是配置详细信息：https://gist.github.com/Geesu/1a696262e46ba9f0a24c 以及local_backup_script.sh：https://gist.github.com/Geesu/3b8b35e108d8e2205da7
谢谢！
答案1
希望这仍然能够回答您的问题，即使我还没有解决您的问题。
所有副本当前是否都处于“恢复中”？对所有副本运行 SELECT pg_is_in_recovery(); 均返回 true，这令人担忧。我们可以对它们运行查询
这是正常的。你的奴隶是尽管恢复过程缓慢而且持续不断，但它仍在从另一台服务器获取 WAL 段（或进行流式传输）。
只是出于某种原因，我无法将我们现有的生产副本流式传输/存档到任何其他服务器。具体来说，archive_command 永远不会在任何副本上运行（因为它卡在恢复模式）。
您是否在任何地方收到错误？请记住，流式传输是由下游从属服务器发起的：它们处于什么状态？它们有什么数据？尝试流式连接时是否记录了任何有趣的内容？请记住，PostgreSQL 的内置流式复制独立于存档系统（假设下游机器是最新的）；您可以代表复制用户建立连接吗？
有人对我如何进一步调试/诊断这个问题有什么建议吗？
考虑到生产和试用之间的不一致，这听起来确实像是隐藏在某处的错误配置，尽管我对 WAL-E 一无所知。 的差异postgresql.conf（pg_hba.conf我recovery.conf想）将是一个无聊但好的开始。 在您的生产奴隶和工作、试用奴隶之间。
您还可以检查pg_settings表。如果这些是长期运行的生产机器，也许只是尚未应用设置？我知道你会查看级联复制及其要求，但我还是将它们链接起来以防万一。