3

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

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

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

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

更新（更多细节）

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

我希望零数据丢失，并愿意为此在故障转移过程中牺牲更多时间。有没有办法在不进行同步复制的情况下进行这种权衡（例如，没有写回确认或其他东西的流式日志）？

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

4

2 回答 2

5

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

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

  1. 你有不止一个奴隶（这很关键！）和
  2. 您需要异步提交无法提供的持久性保证。

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

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

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

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

于 2012-10-07T01:47:49.290 回答
4

回复：“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 上，异步模式似乎以大约一百毫秒左右的时间到达从站（根据我自己的经验）。

于 2012-10-08T05:33:15.053 回答