哪个内置 Postgres 复制最适合我基于 Django 的用例？

Question

我注意到 Postgres 现在具有内置复制功能，包括同步复制、流复制和其他一些变体。它甚至提供了在应用程序级别控制特定操作的同步的能力（例如，将同步用于重要的事情，如汇款，但可能不用于不太重要的事情，如用户 cmets 等）

我正在使用 Django 1.5（即 dev）开发软件，可能需要同步复制（将进行与商务相关的交易）。

您是否认为内置工具在大多数情况下最适合这项工作，您对内置复制的一种变体与另一种变体、易用性相关、质量等有什么想法？

最后一件事； Slony 和 PGPool II 似乎非常流行（尤其是 Slony）用于复制。是否有 A）它们比内置复制更受欢迎的特定技术原因或 B）仅仅是因为很多人正在使用没有内置复制的版本，或者 C）我是否陷入困境而且PG内置复制已经很流行了？

更新（更多细节）

我只有 2 台物理服务器，它们位于同一个机架中。我的目的是提供一个从机，如果一台机器出现灾难性问题（或者甚至像双电源故障等简单的事情），它可以自动变成主机。我不介意我的客户在自动故障转移期间是否会遇到停机，只要停机时间是几分钟左右，而不是一小时左右。

我希望实现零数据丢失，并愿意为此在故障转移过程中牺牲更多时间。有没有办法在不进行同步复制的情况下进行权衡（例如，流式传输日志而无需回写确认等）？

您会推荐什么策略或复制变体？

Answer 1

我认为您误解了同步提交对复制的好处和成本。在 PostgreSQL 中，复制通过使用 PostgreSQL 的标准崩溃恢复功能将从属恢复到主控来工作。例如，在断电的情况下，您可以确保预写日志段将同时在主服务器和从服务器上运行。使用异步提交，将提交写入 WAL，通知应用程序并根据网络特性或多或少同时通知从站等。

同步提交派上用场的地方有两点是正确的：

1. 您有多个奴隶（这很关键！）并且
2. 您需要异步提交无法提供的持久性保证。

使用同步提交，数据库会一直等待，直到收到可配置数量的从属设备的回复，以告知应用程序提交已发生。这在异步提交无法工作的少数情况下提供了持久性保证。

例如，假设您的主服务器通过一个 RAID 阵列获得子弹并立即崩溃（抱歉，我想不出任何具有良好硬件的更好示例）。或者假设有人被电源线绊倒，不仅关闭了服务器电源，而且损坏了软件 RAID 设备。在这种情况下，可能有几个事务可能没有被复制并且您的 WAL 是不可恢复的，因此这些事务会丢失。使用同步提交，应用程序会一直等到满足持久性保证。

这意味着如果您只使用一个从属服务器进行同步提交，那么您的可用性不会超过主服务器或从属服务器上的崩溃，因此您的可用性将比仅使用一台服务器时更差。这也意味着，如果您的从属设备在地理上被移除，那么您在应用程序提交事务的请求中会引入显着的延迟。

从异步提交到同步提交并没有太大的变化，但总的来说，我认为当你已经在硬件上尽可能多地保证和可用性时，你会获得最大的同步提交。当您无法进一步优化您的异步设置时，请从异步开始。

Answer 2

回复：“Slony 和 PGPool II 似乎在复制方面非常受欢迎（尤其是 Slony）。是否有 A）它们比内置复制更受欢迎的特定技术原因或 B）仅仅是因为很多的人正在使用没有内置复制功能的版本，或者 C) 我是否已经陷入困境并且 PG 内置复制功能已经很流行了？”

Slony 之所以流行是因为它已经存在了很长时间，而且内置的 PostgreSQL 复制相对较新。内置到 PostgreSQL 中的级联复制甚至更新，并且是 Slony-I 构建的。

Slony-I 有两个主要优点，首先，您可以在不同版本的 PostgreSQL 之间进行复制，而内置的复制系统不仅必须使用相同的版本，而且两台服务器还必须是二进制兼容的。另一个优点是您只能复制 Slony-I 上的某些表，而不是整个数据库集群。 Slony-I 的缺点很多，包括用户友好性差、没有同步提交和难以更改 DDL（模式）。我相信在 Postgres 中使用内置复制将很快超过 Slony-I 用户群，如果它还没有这样做的话。

据我所知，PGPool II 使用基于语句的复制（就像 MySQL 内置的一样），在我看来，这绝对是最不可取的。

我会在 PostgreSQL 中使用内置的热备份/流式复制。您可以从打开同步提交开始，如果您不需要它或惩罚太高，则将其关闭，反之亦然。在 LAN 上，异步模式似乎以大约一百毫秒左右的时间到达从站（根据我自己的经验）。