[erlang-questions] RFC: mnesia majority checking

[Ulf Wiger]

I added majority checking in the mnesia_locker as well.
The main reason for doing so (except aborting earlier),
was to enable majority checking on reads.

The way it works now is that majority checking is done on 
reads that use a write lock (e.g. mnesia:wread/1).
A normal read, with a read lock, will succeed even in a 
minority. This is probably a pretty good thing.

https://github.com/uwiger/otp/commit/650f8e30d205bc1130f37c819f920f901358b937

Comments still most welcome. Monologues are fun too, but
I can follow Dan North's advice and get a rubber duck for that.

If you are unsure whether this is at all needed, please chime in.
It's is most definitely not a stupid question.

BR,
Ulf W

On 9 Dec 2010, at 15:26, Ulf Wiger wrote:

> 
> git fetch git://github.com/uwiger/otp mnesia-majority
> 
> https://github.com/uwiger/otp/commit/d97ae7d4329d9342e576f3cdd893de6865449e42
> 
> This is a first stab at a function that I believe could be useful in 
> high-availability applications using mnesia.
> 
> At this stage, I'd love to have some comments, and suggestions,
> if someone thinks of a better way to do it.
> 
> From the commit message:
> 
> "Add {majority, boolean()} per-table option.
> 
> With {majority, true} set for a table, write transactions will
> abort if they cannot commit to a majority of the nodes that
> have a copy of the table. Currently, the implementation hooks
> into the prepare_commit, and forces an asymmetric transaction
> if the commit set affects any table with the majority flag set.
> In the commit itself, the transaction will abort if it cannot
> satisfy the majority requirement for all tables involved in the
> thransaction.
> 
> A future optimization might be to abort already when a write
> lock is attempted on such a table (/-object) and the lock cannot
> be set on enough nodes.
> 
> This functionality introduces the possibility to automatically
> "fence off" a table in the presence of failures.
> 
> This is a first implementation. Only basic tests have been
> performed."
> 
> One particular use of this functionality would be to have  a "global 
> resource pool" in one table with {majority, true}, and periodically 
> check out resources into a local buffer. If there is a failure condition,
> you can use the local buffer, but not check out more resources, unless
> you happen to still be in contact with more than half of the replicas.
> 
> This should allow for a well-defined merge after a network split.
> 
> BR,
> Ulf W
> 
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
> 
> 
> 

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com