我想有一个Erlang节点的主从设置,其中读写操作只发生在主节点上。从属节点仅保留为热备用。Mnesia异步事务
据我所知,Mnesia的默认行为是在执行写操作之前在所有节点上同步获取锁。这会导致高延迟,特别是对于地理上分散的节点。
我的问题是:Mnesia是否支持异步事务,其中锁只能在主节点上获取,并且写操作之后会向从节点传播?
我想有一个Erlang节点的主从设置,其中读写操作只发生在主节点上。从属节点仅保留为热备用。Mnesia异步事务
据我所知,Mnesia的默认行为是在执行写操作之前在所有节点上同步获取锁。这会导致高延迟,特别是对于地理上分散的节点。
我的问题是:Mnesia是否支持异步事务,其中锁只能在主节点上获取,并且写操作之后会向从节点传播?
我认为如果使用消息队列系统(rabbitmq或许)从消息队列提要中自己更新复制数据库来构建此场外复制,您会更高兴。广域网链路更有可能变得拥塞或宕机,并且消息队列协议有办法处理这种情况。 Erlang分发只是放弃了,你必须将更新传播到文件中,直到副本出现并可以使用它。
为获得最佳对称性,请将发布到消息队列作为更新数据库的主要方法。所以即使是从消息队列中消耗主机也是如此。如果需要响应,则当前主控可以将消息发送回消息的发布者。
Mnesia确实有几种不同的mnesia transaction contexts,但没有什么真正符合你想要的。
有趣的Q和同样有趣的A!
基本上,你的建议是基督徒,例如,有一个gen_server - 序列化对数据库的访问。 第一次我做到了,然后我意识到:坚持下去! Mnesia是事务性的,所以对于首次序列化访问听起来有点奇怪,然后通过事务更新数据库来重新做一遍。
但是,我仍然有点困惑,因为mnesia强制执行事务性语义我倾向于认为你不应该序列化访问你自己,特别是因为mnesia的实现者可能比我更了解系统做;)
据我所知,这不是一个直接回答你的问题,但是,我会说使用mnesia + memorynodes + disknodes。用于快速接管的内存节点以及在崩溃/备份后用于恢复的磁盘节点。
HTH, haavee
也许你的应用可以受益使用粘锁。我想这是非常接近你的需求,但是...不完全是你想要的http://www.erlang.org/documentation/doc-5.8.3/lib/mnesia-4.4.17/doc/html/Mnesia_chap4.html#id70700
我也调查了一下,因为我看到这个问题:Christian的建议听起来很明智。 – jldupont 2009-12-14 01:50:18