Mnesia 异步事务
我想要一个 Erlang 节点的主从设置，其中读写操作仅发生在主节点上。从节点仅保留为热备。
据我了解，Mnesia 的默认行为是在执行写操作之前在所有节点上同步获取锁。这将导致高延迟，尤其是对于地理上分散的节点。
我的问题是：Mnesia 是否支持异步事务，即仅在主节点上获取锁，然后将写操作传播到从节点？
I would like to have a master-slave setup of Erlang nodes, where read and write operations happen on the master node only. Slave nodes are only kept as hot-standbys.
As I understand the default behavior of Mnesia is to acquire the lock synchronously on all nodes before executing the write operation. This would result in high latency especially for geographically distributed nodes.
My question is: does Mnesia support asynchronous transactions, where locks are only acquired on the master node, and write operations are propagated afterwards towards slave nodes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为，如果您使用消息队列系统（也许是rabbitmq）构建此异地复制，并自己从消息队列提要更新复制的数据库，您会更高兴。 WAN 链路更有可能变得拥塞或宕机，消息队列协议有办法处理这个问题。 Erlang 发行版就放弃了，你必须将更新溢出到一个文件中，直到副本出现并可以使用它。
为了获得最佳对称性，请将发布到消息队列作为更新数据库的主要方法。因此，即使是 master 也是通过从消息队列中消费来更新的。如果需要响应，当前主站可以将消息发送回消息的发布者。
Mnesia 确实有几种不同类型的 mnesia 事务上下文，但是没有什么真正符合你想要的。
I think you will be happier if you build this off-site replication using a message queue system (rabbitmq perhaps) updating the replicated db yourself from the message queue feed. WAN links are more likely to become congested or go down, and message-queue protocols have ways to handle that. Erlang distribution just give up and you have to spill the updates into a file until the replica comes up and can consume it.
For best symmetry, have posting-to-the-message queue be the primary method to update the db. So even the master is updated by consuming from the message queue. If a response is needed, the current master can send a message back to the issuer of the message.
Mnesia does have a few different kinds of mnesia transaction contexts but nothing that really fit exactly with what you want.
也许您的应用程序可以使用粘性锁受益。我想它非常接近您的需求，但是...不完全是您想要的http://www.erlang.org/documentation/doc-5.8.3/lib/mnesia-4.4.17/doc/html/Mnesia_chap4.html #id70700
Maybe your application can benefit using sticky locks. I guess that it is quite close to your needs, but...not exactly what you wanted http://www.erlang.org/documentation/doc-5.8.3/lib/mnesia-4.4.17/doc/html/Mnesia_chap4.html#id70700
有趣的 Q 和同样有趣的 A！
基本上，克里斯蒂安，您的建议是拥有一个 gen_server - 序列化对数据库的访问。
我第一次这样做，然后我意识到：坚持住！ Mnesia 是事务性的，因此首先序列化访问然后通过事务更新数据库来再次执行此操作听起来有点奇怪。
然而，我仍然有点困惑，考虑到 mnesia 强制执行事务语义，我倾向于将其视为您不必自己序列化访问的暗示，特别是因为 mnesia 的实现者可能比我更了解系统;)
我了解这并不是对您问题的直接回答，但是，我会说使用 mnesia + memorynodes + disknodes。用于快速接管的内存节点和用于在崩溃/备份后恢复的磁盘节点。
哈特哈，
哈维
Interesting Q and equally interesting A!
Basically, what you are suggesing, Christian, is e.g. to have a gen_server - serializing the access to the DB.
First time I did that and then I realized: hang on! Mnesia is transactional so it sounds a bit odd to first serialize access and then sort of do it again by updating the DB via a transaction.
I still am a bit puzzled, however, given that mnesia enforces transactional semantics I tend to take that as a hint that you should not have to serialize access yourselves, especially since the implementors of mnesia probably know the system better than I do ;)
I understand that this is not quite a direct answer to your question, however, I'd say use mnesia + memorynodes + disknodes. The memorynodes for quick takeover and the disknodes for recovering after a crash/backup.
HTH,
haavee