我注意到Postgres现在具有内置复制功能，包括同步复制，流复制和其他一些变体。它甚至提供了在应用程序级别控制特定操作的同步的能力（例如，对于诸如汇款之类的重要事项使用同步，但可能不会用于诸如用户评论之类的不太重要的事情。）
我正在使用Django 1.5（即dev）开发一个软件，可能需要同步复制（将会进行与商业相关的交易）。
您认为内置工具在大多数情况下最适合这项工作吗？您是否对内置复制的另一种变体，相关易用性，质量等有任何想法？< / p>
最后一件事; Slony和PGPool II似乎非常流行（特别是Slony）用于复制。有没有A）特定的技术原因，因为它们比内置复制更受欢迎，或者B）是因为很多人使用的是没有内置复制的版本，或者C）我是否曾经在岩石下和PG内置复制已经非常流行了吗？
我只有2台物理服务器，它们位于同一个机架中。我的目的是提供一个可以自动变成主机的从机，如果在一台机器上发生了某些特定的错误（或者甚至是像双电源故障那样简单的事情等）。我不介意我的客户在自动故障转移期间遇到停机时间，只要停机时间是几分钟左右，而不是一小时或者其他什么。
我希望零数据丢失，并愿意在故障转移过程中牺牲更多时间。有没有办法在不进行同步复制的情况下进行此交易（例如，没有回写确认的流式传输日志）？
您会推荐哪种策略或复制变体？
答案 0 :(得分：5)
我认为您误解了同步提交复制的好处和成本。在PostgreSQL中，复制的工作原理是使用PostgreSQL的标准崩溃恢复功能将从属服务器恢复到主服务器。例如，如果电源耗尽，您可以确保预写日志段将在主服务器和从服务器上运行。使用异步提交，将提交写入WAL，通知应用程序，并根据网络特征等同时或多或少地通知从属设备。
同步提交派上用场的地方有两件事：
使用同步提交，数据库会等待，直到它从可配置数量的从服务器回来，告诉应用程序提交已发生。这在异步提交无法工作的少数情况下提供了持久性保证。
例如，假设您的主服务器通过raid阵列获取子弹并立即崩溃（抱歉，我想不出任何有良好硬件的更好示例）。或者假设某人使用电源线绊倒，不仅关闭了服务器电源，还破坏了软件RAID设备。在这种情况下，可能没有复制一些事务并且您的WAL无法恢复，因此这些事务将丢失。使用同步提交，应用程序将等待，直到满足耐久性保证。
这意味着，如果您只使用一个从属设备进行同步提交，则您的可用性不会超过主服务器或从服务器上的崩溃，因此您的可用性将比仅使用一台服务器时更糟糕。这也意味着，如果您的slave在地理位置上被删除，那么您在应用程序提交事务的请求中会引入显着的延迟。
从异步切换到同步提交它并不是一个很大的改变，但一般来说，我认为当你已经完成了尽可能多的保证和硬件可用性时，你得到了最多的同步提交。当您无法将设置进一步优化为异步时，请从异步开始并向上移动。
答案 1 :(得分：4)
Re：＆＃34; Slony和PGPool II似乎非常受欢迎（特别是Slony）用于复制。有没有A）特定的技术原因，因为它们比内置复制更受欢迎，或者B）只是因为很多人使用的是没有内置复制的版本，或者C）我是否已经摇滚和PG内置复制已经很受欢迎了？＆＃34;
Slony很受欢迎，因为它已存在很长时间了，内置的PostgreSQL复制相对较新。内置于PostgreSQL的级联复制甚至更新，并且是Slony-I构建的。
Slony-I有两个主要优点，首先，您可以在不同版本的PostgreSQL之间进行复制，而内置复制系统不仅必须使用相同版本，而且两个服务器也必须是二进制兼容的。另一个优点是您只能复制Slony-I上的某些表而不是整个数据库集群。 Slony-I的缺点很多，包括用户友好性差，没有同步提交，以及难以进行DDL（模式）更改。我相信在Postgres中使用内置复制很快就会超过Slony-I用户群，如果还没有这样做的话。
据我所知，PGPool II使用基于语句的复制（就像MySQL内置的那样），在我看来绝对是最不可取的。
我会在PostgreSQL中使用内置的热备份/流式复制。您可以从启用同步提交开始，如果您不需要它或者惩罚太高，则将其关闭，反之亦然。通过局域网，异步模式似乎以大约一百毫秒左右的速度到达从站（根据我自己的经验）。