PostgreSQL故障转移和复制

我正在评估PostgreSQL 9.1，并且有几个与故障转移和复制详细信息有关的问题。

我有几个测试方案。第一个具有主服务器和少量从属服务器的服务器。万一Master崩溃了，我希望其中一个Slave成为Master。主服务器恢复到正常状态后，它应与群集中的其他服务器同步（应用关闭状态下所做的所有更改），并退回主服务器角色或成为从服务器。

我在PostgreSQL和当前场景中看到的问题如下。

1）我没有看到用于检测主服务器故障的内置工具。我读到pgpool可以处理它并创建触发文件，我还读到人们为此使用Linux心跳或类似工具。好的，我可以检测故障转移并在群集中分配一个新的主服务器。其他的奴隶们会明白有一个新的主人，他们现在应该备份吗？

2）我不了解故障回复程序。主从主机配置不同。那么崩溃的Master故障回复后，我将拥有两个Master吗？服务器将如何恢复同步？我只看到手动解决方案，例如“将数据文件夹传输到服务器并重新启动它”。那么什么是解决方案或最佳实践，或者至少是关键原则？

3）我应该如何处理客户端的服务器中断？创建连接时，我明确指定服务器IP。我是否应该开发某种会知道我的主从结构的ConnectionManager，仅将请求发送到主服务器，并且在连接断开的情况下将切换到备用服务器等？我读到pgpool可以成为应用程序的入口点，并以正确的方式管理连接。pgpool是这里唯一的解决方案吗？它能否很好地处理故障转移和故障回复？

4）是否有解决方案（也有商业解决方案），所以我可以避免手动复制数据，重新配置PostgreSQL实例和其他应由人工完成的工作？当每个人都同步时，这样的集群配置就很清楚，谁是主服务器，一切都会自动切换而无需操作员注意？

根据这些主题和文章

在PostgreSQL上进行流式复制和故障转移

PostgreSQL 9.1中的自动故障转移

http://denishjpatel.blogspot.com/2010/11/possibility-of-graceful-switchover.html

没有单一的全自动解决方案可以解决这些问题。我对吗？

谢谢！

1. 奴隶不会理解新主人。您应该手动执行此操作。

2. 是的，它们是不同的，您应该为旧的master创建新的。但是，旧的standby将继续作为master工作，但是您应该在该节点上设置max_wal_senders。故障转移后，还应该设置新主服务器的pg_hba.conf。故障转移后（当节点更改角色master-> slave slave-> master时），您应该将新的wal文件传输到在recovery.conf文件中设置的新备用文件夹数据目录中。或者您也可以使用rsync。

3. 可能是您可以使用pgbouncer。这样，您只需将pgbouncer服务器地址更改为新的主服务器即可。

4. EnterpriseDB有一些商业工具。可能是您可以检查它们。

最后是的，你是对的。没有单一的全自动解决方案可以解决这些问题。