[erlang-questions] auto-syncing mnesia after a network split

[Jim McCoy]

Vector clocks don't really work that way, you can only update the
vectors at the point where messages pass between nodes.  Using your
example, if D splits off, reboots and has its clock reset slightly,
records a few local transactions using this new clock, and then
rejoins you will need to figure out how to order the local
transactions with the state of the rest of the nodes.

Consistence, availability, partition-tolerance: pick two.

Simiarly, Claes is incorrect in assuming that you could use the system
clock for anything other than printing a nice little display on the
screen to remind the user that they have a meeting scheduled for some
point in the near future.  There is _a lot_ of literature out there on
distributed transaction fault-tolerance and it gets pretty complex in
a hurry.

To maintain the current properties of mnesia I believe the only option
would be to add some complexity on the mechanics of the join mechanism
(e.g. a quorum system like paxos to decide membership and agreement
among the nodes as to the minimum quorum below which a partitioned
subset is read-only) and a bit of work to change a minority subset
into read-only mode when a partition is discovered.

On Mon, Dec 8, 2008 at 7:36 AM, Joel Reymont <joelr1@REDACTED> wrote:
>
> On Dec 8, 2008, at 3:31 PM, Claes Wikstrom wrote:
>
>> Joel Reymont wrote:
>>>
>>> I mean to say that if I am node A and I know what the clock is on
>>> nodes B, C and D then it doesn't matter if our clocks aren't
>>> perfectly synchronized by NTP. I will know the skew and once node D
>>> splits off and rejoins, I'll be able to compare the timestamp on my
>>> transactions vs those on node D using that skew.
>>
>> No,
>
>
> Why?
>
> --
> http://wagerlabs.com
>
>
>
>
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>