要使用哪个Postgresql复制解决方案？(异步多播/布卡多？)

Question

首先，我不是一个DBA，所以请原谅我，如果这个问题似乎“关闭”。

我已经编写了一个对等多人游戏(客户端)，它连接到多个服务器之一进行匹配。

目前，只有一台服务器(让我们称之为服务器1)运行游戏的自定义匹配过程和PostgreSQL 8.4 (如果需要，我将将其升级到9.1、9.2或9.3 )。

匹配过程对所有SQL语句异步使用libpq。语句并不太复杂，因此负载平衡不是一个问题。

我计划添加更多的linode(称为服务器2、3、4等)。在必要时运行匹配过程和PostreSQL。挑战在于，我希望所有客户都能获得高可用性。如果无法访问服务器1，则可以使用服务器2来访问所有相同的数据。

最初的计划是让所有服务器连接到Server 1's数据库，并通过libpq异步发送SQL语句。问题是，如果服务器1暂时脱机或无法访问，那么其他服务器都会失败。

我能想象到的“最简单”的解决方案是让每个服务器完全镜像数据库。如果服务器1故障，客户端可以连接到服务器2，服务器2可以读写到自己的数据库，立即复制对服务器3和4的任何更改，并在服务器1恢复联机后复制到服务器1。

以这种方式，每个服务器都将保存数据库的整个“镜像”副本。

在阅读了PostgreSQL 9.3's复制文档的介绍部分之后，实现此解决方案的方法似乎是异步多主复制。(布卡多是这里唯一的选择吗？)

对于异步复制，我担心的是SQL插入。当第一次播放新客户端时，将创建一个player数据库条目。如果服务器2、3和4联机，服务器1脱机，那么如果2插入新的播放机行，1、3或4会出现问题吗？(想象一下，1返回在线，然后立即尝试插入另一个玩家行。)

对于上述场景，异步多主是否是正确的方式？

或者，有一个更简单或更简单的解决方案，我忽略了吗？也许一个不需要中间件，但只是使用PostgreSQL 9.3's内置的复制？

Answer 1

如果您不是DBA --也就是说，您不熟悉复制、故障转移、事务隔离的微妙性等方面的复杂性--那么如果可能的话，不要使用多主服务器。

PostgreSQL没有多主群集，只有通过第三方附加组件进行多主复制。这些附加组件具有显著的性能影响，但更重要的是它们不处理节点间锁定和事务隔离。不同节点上的并发事务可以看到不同的数据，都可以修改相同的行等。

坦率地说，多主集群是相当平淡无奇的，即使在有它可用的产品中也是如此。性能往往很差，规模也很差。这不是产品的缺陷，只是MM集群很难，您可以选择正确或快速。

就个人而言，我建议使用两个大节点。让一个节点运行一个流副本，另一个节点作为主节点运行。如果其中一个失败了，那就失败给另一个。在添加更多容量之前，要正确地调整应用程序和查询。

Answer 2

我也在寻找有关这件事的资料。我偶然发现了以下开源项目。

http://2ndquadrant.com/en/resources/bdr/

它们还提供了性能部分下可用的各种解决方案的一些基准。