PostgreSQL 9.1 的自动故障转移答案

【问题标题】：Automatic failover with PostgreSQL 9.1PostgreSQL 9.1 的自动故障转移
【发布时间】：2017-08-17 03:30:14
【问题描述】：

PostgreSql 9.1 有主从同步复制。假设master是机器A，slave是机器B。

如果 master 失败了，PostgreSQL 怎么知道什么时候让 slave 成为 master？如果从服务器错误地认为主服务器由于主服务器上的临时网络故障而导致客户端程序仍然可以联系主服务器，该怎么办。

此外，我的客户端程序如何知道新主机中的从机，更重要的是准备好接受写入。从站是否向客户端发送消息？

【问题讨论】：

【解决方案1】：

检查repmgr，它的工作之一就是处理这个问题。

【讨论】：

虽然它明确不处理 STONITH，但在某些用途中可能仍需要一些外部工具。它也不为客户端执行基于 IP 的故障转移或代理，因此您需要 plproxy 或类似的东西。它很有帮助，但还不是一个完整的解决方案。
我不推荐任何人使用repmgr；在这一点上，这对我来说只不过是一个时间沉没
@FrankHeikens 我发现它有问题，设计不佳且文档记录不佳。我认为它可以很好地抽象出我正在做的一些 dev-ops 脚本的 postgres 复制和故障转移的一些粗糙细节，但相反，我花了更多的时间对 repmgr 的粗糙细节进行逆向工程，并且仍然不得不担心关于粗糙的 postgres 细节，我留下了一个我不完全理解的系统，而不是我理解的系统。
@jberryman 你和repmgr 开发人员谈过这个吗？您对他们通过邮件列表提供支持的体验如何？
@jberryman 这里有同样的问题。多么浪费。我会对你最终得到的结果非常感兴趣。

【解决方案2】：

通常您希望使用诸如repmgr 或patoni 之类的促销管理系统。然后你想使用某种高可用性代理（可能是 pgbouncer 或 haproxy）来处理实际的抽象，这样你的应用程序就不需要知道哪个系统是主系统。

在回答您的问题时，这些系统中的大多数都使用心跳来确定是否存在问题。 Patroni 退出 etcd 心跳。 Repmgr 有自己的心跳检查。使用 Repmgr，您需要编写挂钩脚本来处理 stonith，等等。

【讨论】：