目前我正在开发一个游戏服务器，我的架构是每个游戏服务器在首次启动时都会实例化一个 mnesia db。 假设我想创建第二个节点，我的计划只是将相同的游戏服务器部署到第二个节点。
我的问题是：我希望我的游戏服务器的第二次部署会自动检测第一个节点上的 mnesia 实例，复制其 db 架构并成为第一个节点的集群。
我在http://code.google.com/p/schemafinder/ 上查看了 schemafinder 项目，我想实现它是如何做到的，但它似乎相当复杂。
如果有人愿意给我一些启发，我将不胜感激。
提前致谢
【问题讨论】：
您希望在一组机器上使用相同的游戏服务器。您采取的第一步是好的：通过远程机器上的复制使其数据库可用。然而，分层设计整个游戏服务器很重要。让游戏服务器自己成为自己的应用程序，自己的包。然后将其数据库也单独设计。该数据库可以分段，在多台机器上复制。
通过这种方式，您可以为您的游戏服务器创建一个数据访问层，在该层中，它将使用数据访问层 API 访问您的数据库，无论是在远程机器上还是在本地在运行时不会中断服务。让每个游戏服务器实例都有自己的 Mnesia Schema 是不好的，除非您确定将驻留在这些数据库中的数据不会相关：{local_content,true}。
在多台机器上复制相同的 Mnesia Schema（这是在您的数据存储层中）更安全。然后你的桌子设计得很好。在模块中公开操作您的游戏数据的 API。从这里开始构建数据访问层（
<b>NOTE: Am talking of the 3-tier Logical Architecture, the Physical Architecture can take any form as long as it caters for Hardware and Network Failures.</b>)。在数据访问层，构建了容错数据库节点访问。您放在这里的方法将从处理连接问题中抽象出应用程序（业务逻辑）层，对数据库节点等进行远程过程调用。此外，这些方法应该能够检测“节点无法访问”错误，并且可以在运行时重试对另一个数据库副本节点的调用，而游戏服务器不会注意到这种干扰。
数据访问层可以通过在数据库节点之间有效地多路复用应用程序到数据库的调用来在数据库节点上进行负载平衡（取决于可用性和故障转移机制）。
话不多说……
无论如何，我总结的一点是，将 Mnesia 与游戏服务器分开很重要。通过这样做，您可以单独管理服务器应用程序，以后还可以单独担心数据访问。将数据库物理和逻辑布局与项目的其他部分分开将增加灵活性和可用性。将来，您可以在不更改数据访问层的情况下更改数据库设计和内容。您甚至可以在将来切换到另一个 DBMS，例如 Riak 或 Membase Server，而无需更改游戏逻辑。
另一件事：避免到处复制模式。从一开始就设计您复制/分布式的数据库架构。不要让你的游戏服务器为了成为一个集群而从一个节点到另一个节点复制 mnesia 模式。让游戏服务器担心游戏逻辑和其他东西，让数据访问层担心游戏数据。 那里有一些启示，我希望它有所帮助。成功！
【讨论】：