[erlang-questions] Re: how to scale into the cloud using process? example computing simple average

[Ulf Wiger]

Joel Reymont wrote:
> 
> On May 30, 2009, at 1:44 PM, Ulf Wiger wrote:
> 
> I think the only way to solve this would be to keep a separate 
> transaction log. Then you could try to merge the logs from
> disconnected nodes and re-apply transactions in different order to
> build a merged database.
> 
> Then again, who knows what the right order is?

This is one of the reasons why it doesn't happen
automatically. Merging of records after a split-brain
condition is an application-specific problem. 
Personal Information Managers have had this problem for
ages, and usually resort to presenting the user with a 
list of records that couldn't be deconflicted automatically.

Source code merging is another problem with corner cases 
requiring human intervention.


> Either way, it does not bode well to keeping "account balances" in 
> Mnesia for example, since you could easily overdraw your account if
> you manage to hit two disconnected nodes.

...and when building the AXD 301, we were not thrilled by
the prospect of having two control processors simultaneously
controlling the resources in the ATM switch fabric, so we 
designed checks to make sure that the processors would be
able to determine the source of the problem by asking a third
party (the switch).

>> Which DBMSes have a good solution to this problem? How do they do
>> it? And what prevents using the same strategy with mnesia?
> 
> I think Oracle has a solution. I heard that they use 3 copies of the
>  database to settle on a good one.

What prevents you from doing something similar with mnesia?

>> (Mnesia's supposed lack of support for handling partitioned
>> networks has more or less become an urban legend.
> 
> An urban legend is a story that's untrue ;-).

Exactly. :)

>> Everyone assumes that this is a major weakness in mnesia, but there
>> is very little detail about how the competing alternatives 
>> supposedly handle this in a much better way.
> 
> This is mostly because almost no competing alternative tries to build
> a multi-master cluster with real-time replication.

As far as I know, just about all competing alternatives offer
multimaster replication: Oracle, Ingres, MySQL, PostgreSQL,
Sybase, SQL Server and DB2 come to mind.

At least in one or some of those, if memory serves, the way
to recover from partitioned network was to initiate disaster
recovery and restart from a stable backup. In one study, this
was noted as an example of the type of automatic handling of 
partitioned networks that mnesia supposedly was unable to 
provide.

Someone with plenty of time on their hands could perhaps 
inventory the strategies of these products and identify
which of these strategies could not be implemented on top
of mnesia without major surgery.

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd.
http://www.erlang-consulting.com