mnesia question

[Dan Gudmundsson]

Renyi Xiong writes:
 > what if one node participant fails to respond (machine down or network down) 
 > during commit process while the coordinator waiting for commit vote 
 > ('receive' waits forever for a message, right?)
 > 
 > the reason why I'm asking this question is that:
 > 
 > our system is designed to handle thousands of write transactions a second 
 > and to have multiple replicas to provide fault tolerance. if one replica 
 > down and fails to send 'mnesia_down' message. there is a good chance that a 
 > commit process is on going.
 > 
 > does 'mnesia_monitor' on coordinator node handle that?

Yes. :-)

/Dan

 > 
 > Thanks,
 > Renyi.
 > 
 > ----- Original Message ----- 
 > From: "Hakan Mattsson" <hakan@REDACTED>
 > To: "Renyi Xiong" <rxiong@REDACTED>
 > Cc: "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED>; 
 > <erlang-questions@REDACTED>
 > Sent: Tuesday, February 14, 2006 2:04 AM
 > Subject: Re: mnesia question
 > 
 > 
 > On Wed, 8 Aug 2001, Renyi Xiong wrote:
 > 
 > RX> Thanks guys,
 > RX> It's really helpful for us to understand how Mnesia works.
 > RX>
 > RX> 1.My understanding is when one node initiates a write operation it sends 
 > a
 > RX> message to each of the replicas at same time and doesn't care the write
 > RX> transaction status on other replicas. It's up to the transaction handler 
 > on
 > RX> each node to handle the write transaction separately. Is that right?
 > 
 > Yes, this is true for normal transactions using
 > 2pc. But it is not as bad as it sounds as the
 > transaction recovery protocol ensures that the
 > outcome of the transaction always is atomic.
 > 
 > If needed, Mnesia will automatically use 3pc as
 > transaction protocol. It is slower, but takes
 > care of transactions operating on multiple tables
 > which are replicated asymmetrically.
 > 
 > RX> 2.How do I know the write operation succeeds on at least
 > RX> on of the replicas including the one which initiates it?
 > 
 > Use mnesia:sync_transaction/1. It waits for all
 > participating nodes to complete their commit work
 > before it returns. It is slower, but needed in
 > some applications.
 > 
 > /Håkan
 > 
 > RX> Thanks,
 > RX> Renyi.
 > RX>
 > RX> ----- Original Message ----- From: "Hakan Mattsson" 
 > <hakan@REDACTED>
 > RX> To: "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED>
 > RX> Cc: "Renyi Xiong" <renyix1@REDACTED>; <erlang-questions@REDACTED>;
 > RX> <rxiong@REDACTED>
 > RX> Sent: Monday, February 13, 2006 8:54 AM
 > RX> Subject: RE: mnesia question
 > RX>
 > RX>
 > RX> On Mon, 13 Feb 2006, Ulf Wiger (AL/EAB) wrote:
 > RX>
 > RX> UW> Renyi Xiong wrote:
 > RX> UW> >
 > RX> UW> > 1. what happens if one of (not all of) the RAM replicas of
 > RX> UW> > Mnesia table fails when doing write operation? write fails?
 > RX> UW>
 > RX> UW> If you are using transactions, chances are good that mnesia
 > RX> UW> will be able to follow through after all. The transaction
 > RX> UW> is completed as an 'asymmetric' transaction, and the failed
 > RX> UW> node gets the opportunity to update itself later.
 > RX>
 > RX> Yes, the transaction is completed consistently on the
 > RX> surviving nodes. On the node(s) where Mnesia fails to
 > RX> write, Mnesia will be terminated. When Mnesia later is
 > RX> started on these nodes, it will pick the table contents
 > RX> from the surviving node(s). This fundamental behavior
 > RX> is the same for all types of transactions as well as
 > RX> for dirty writes.
 > RX>
 > RX> For transactions using 3pc, the recovery procedure is
 > RX> more complicated as the failing nodes may need to
 > RX> determine the outcome of the transaction before the
 > RX> transaction log can be processed. 3pc is used for
 > RX> transactions involving updates of the schema or
 > RX> asymmetrically replicated tables.
 > RX>
 > RX> UW> (Of course, assuming that the failed node is not the
 > RX> UW> one  that initiated the transaction.)
 > RX>
 > RX> The recovery procedure is the same, even if it was the
 > RX> failing node that initiated the transaction.
 > RX>
 > RX> UW> If you're using dirty writes, you may end up with
 > RX> UW> database inconsistency. Don't use dirty writes on
 > RX> UW> replicated tables unless you really really know what
 > RX> UW> you're doing.
 > RX>
 > RX> This is a good general advice.
 > RX>
 > RX> Using dirty writes on replicated tables, is about as
 > RX> hazardous as using master nodes, using the
 > RX> max_wait_for_decision configuration parameter or to
 > RX> force load tables. Elaborating with these mechanisms
 > RX> may easily end up with an inconsistent database as
 > RX> they bypasses the transaction recovery procedure in
 > RX> Mnesia. Sometime it is necessary to use these
 > RX> mechanisms, but use them with care.
 > RX>
 > RX> /Håkan
 > RX>
 > RX> UW> > 2. Is Mnesia table RAM replica distributable across VPN network?
 > RX> UW>
 > RX> UW> If you can get Distributed Erlang to work, you will be able to
 > RX> UW> replicate mnesia tables. Without Distributed Erlang - no 
 > replication.
 > RX> UW>
 > RX> UW>
 > RX> UW> > 3. Is possible to add and remove RAM replica dynamically?
 > RX> UW>
 > RX> UW> Yes, using the function
 > RX> UW>
 > RX> UW>   mnesia:add_table_copy(Tab, Node, Type)
 > RX> UW>
 > RX> UW> where Type == ram_copies, if it's a RAM replica you want to add.
 > RX> UW>
 > RX> UW> Removing a replica:
 > RX> UW>
 > RX> UW>   mnesia:del_table_copy(Tab, Node)
 > RX> UW>
 > RX> UW> Regards,
 > RX> UW> Ulf W