Nat*_*iss 5 postgresql replication
首先，我不是 DBA，所以如果这个问题中的任何一个看起来“离题”，请原谅我。
我编写了一个点对点多人游戏（客户端），它连接到多个服务器之一进行匹配。
目前，只有一台服务器（一个 linode，我们称之为服务器 1）运行游戏的自定义匹配流程和 PostgreSQL 8.4（如有必要，我会将其升级到 9.1、9.2 或 9.3）。
匹配过程对所有 SQL 语句异步使用 libpq。语句不太复杂，因此负载平衡不是问题。
我计划添加更多 linode（称为服务器 2、3、4 等），以根据需要运行匹配过程和 PostreSQL。挑战在于我希望为所有客户提供高可用性。如果服务器 1 无法访问，则可以使用服务器 2 代替，访问所有相同的数据。
最初的计划是让所有服务器连接到服务器 1 的数据库并通过 libpq 异步发送 SQL 语句。问题在于，如果服务器 1 暂时离线或无法访问，那么其他所有服务器都将失败。
我能想象的“最简单”的解决方案是让每个服务器完全镜像数据库。如果服务器 1 关闭，客户端可以连接到服务器 2，后者读取和写入其自己的数据库，立即将任何更改复制到服务器 3 和 4，并在服务器 1 重新联机后复制。
以这种方式，每台服务器都将保存数据库的完整“镜像”副本。
在阅读了PostgreSQL 9.3 关于复制的文档的介绍部分后，似乎实现这个解决方案的方法是异步多主复制。（Bucardo 是这里唯一的选择吗？）
我担心异步复制是 SQL 插入。当新客户端第一次玩游戏时，会创建一个玩家数据库条目。如果服务器 2、3、4 在线而服务器 1 离线，如果 2 插入新的玩家行，1、3 或 4 会不会有任何问题？（想象一下 1 重新上线并立即尝试插入另一个玩家行。）
对于上述场景，异步多主节点是正确的方法吗？
或者，是否有我忽略的更简单或更容易的解决方案？也许不需要中间件，而只使用 PostgreSQL 9.3 的内置复制？
如果你不是一个DBA -即你没有经历过与复制，故障恢复，事务隔离的微妙之处等复杂-然后如果可能的话就不能使用多主机。
PostgreSQL没有多主集群，只有通过 3rd 方附加组件的多主复制。这些附加组件具有显着的性能影响，但更重要的是它们不处理节点间锁定和事务隔离。不同节点的并发事务可以看到不同的数据，都可以修改相同的行等。
坦率地说，即使在有它可用的产品中，多主集群也相当平庸。性能往往很差，而且扩展性很差。这不是产品的缺陷，只是 MM 聚类很难，您几乎可以选择正确或快速。
我个人建议使用两个大节点。让一个节点运行流式副本，另一个节点作为主节点运行。如果一个出现故障，则故障转移到另一个。在添加更多容量之前正确调整您的应用程序和查询。
| 归档时间： |
|
| 查看次数： |
10686 次 |
| 最近记录： |