[erlang-questions] RFC: mnesia majority checking

[Alain O'Dea]

The guys at Basho probably have some excellent material on partition
tolerance related to Riak.  It is worth a chat with Justin Sheehy or Andy
Gross to see what insight they have.

On Thu, Dec 9, 2010 at 1:55 PM, Ulf Wiger <ulf.wiger@REDACTED>wrote:

>
> 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
>
>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>