mnesia question

[Hakan Mattsson]

On Thu, 16 Feb 2006, Renyi Xiong wrote:

RX> what if one node participant fails to respond (machine down or network down)
RX> during commit process while the coordinator waiting for commit vote
RX> ('receive' waits forever for a message, right?)

Mnesia detects that and re-runs the transaction. Se below.

Transaction recovery is a fundamental functionality in
Mnesia as well as in all other DBMS's.

RX> the reason why I'm asking this question is that:
RX> 
RX> our system is designed to handle thousands of write transactions a second
RX> and to have multiple replicas to provide fault tolerance. if one replica
RX> down and fails to send 'mnesia_down' message. there is a good chance that a
RX> commit process is on going.
RX> 
RX> does 'mnesia_monitor' on coordinator node handle that?

Yes, all mnesia_monitor's are linked to each others.
When mnesia_monitor detects that some of the others are
down, it will tell all coordinators and participants
(via mnesia_tm) on the local node about it. The
coordinators and participants will then act accoringly
and recover their own transactions.

/Håkan

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