On Mon, Apr 20, 2009 at 10:40:28AM -0500, David Teigland wrote: > On Sat, Apr 18, 2009 at 09:30:39AM +0200, Dietmar Maurer wrote: > > > Once a partition exists, a merge back together doesn't change the fact > > > that the disagreement has already occured (at partition time) and that > > > disagreement can only be resolved (to maintain VS) by killing nodes that > > > don't agree with one version of the history. > > > > Sure, but the whole problem is 'how do I merge states reliable'? I an > > application can merge any states there is no problem at all? > > If your application requires virtual synchrony, then the only way to handle > partitions is to terminate one part (and force it to restart with no history) > to preserve a common history among the remaining nodes. Merging doesn't make > sense because the VS history has already diverged.
I should clarify what I mean by terminate/restart/reset, because it depends on the specific application. For some apps, an instance that became partitioned and then merged may be able to abandon former state/history and resync with the main group without exiting or explicitly leaving and rejoining the cpg. The key point is that two cpg members (A and B) with different event histories will have inconsistent state, assuming that the state is derived from the history. So, after they are partitioned and merged, A needs to replace its own state/history with B's or v.v. Dave _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
