我目前正在为我的组织邮件设置规划一个容错性更强的设置。我们目前在不同的数据中心有两台机器，我们计划将它们用于此，一台是物理主机，另一台是 lxc“VM”。
计划是通过 DNS 将物理主机设为我们的主要邮件服务器（我们称之为 server1），并将 VM（我们称之为 server2）设为辅助服务器，这样当 server1 发生故障时，server2 可以接管，直到我们重新启动并运行另一个服务器。
与 lxc 一样，由于权限问题，我无法使用 DRBD 甚至 GlusterFS 等花哨的东西，我复制数据的选择相当有限。
由于我个人喜欢 dbmail，所以我考虑过使用它并在其背后使用 Postgres 来处理存储。所以基本上我考虑在服务器 1 上运行 dbmail 及其自己的 postgres，并在服务器 2 上运行另一个 dbmail 和另一个 postgres。
问题是：有什么选项可以使这两个 postgres 服务器保持同步，而无需使用 drbd 或分布式文件系统等花哨的东西，以便当 server1 发生故障时，server2 可以从 server1 停止的地方继续运行。
答案1
这内置复制在数据库中，无论是通过 9.0 及更高版本的流复制功能还是较旧的日志传送方法，都旨在解决此类问题。无论如何，保持数据库的两个文件系统级快照同步都是一个难题。让复制工作起来，如果主服务器发生故障，您必须手动触发备用服务器，然后更改 DNS 地址以指向它。与数据库通信的客户端需要被踢出，以便它们也重新连接；TCP/IP 超时有时可能很长。让所有这些细节都完美无缺需要努力，但没有一种高可用性解决方案是那么简单。硬件可能会以许多奇怪的方式发生故障。
您可以预料到，崩溃时可能会丢失一些数据 — 在主服务器上提交，然后在复制之前关闭。在 PostgreSQL 9.1 中，似乎可以通过同步复制消除这种可能性。但这实际上也不会达到您想要的效果；除非您打开此功能后至少有两台服务器正在运行，否则不会发生任何提交。
这一切都假设所有有趣的状态信息都在数据库内，每个 dbmail 都不存在这些信息。想必您知道这不是问题。
答案2
在容错系统的主服务器和辅助服务器上采用不同的设置几乎总是一个坏主意。
我可以看到一个选项，您可以运行 PostgreSQL 复制和标准 Linux 集群软件（heartbeat 等）来切换角色。您还必须管理 IP 地址，而不是将辅助 IP 地址放入您的邮件 DNS 中。