On Fri, Feb 26, 2010 at 2:57 AM, Andrew Beekhof <and...@beekhof.net> wrote:
> Not only safe but essential, otherwise B would kill A for no reason. > Transitional memberships are just corosync's way of saying "i;m still > working, but this is what I have so far". > The best explanation I've found for the transitional membership is in: "Group Communication Specifications: A Comprehensive Study" 1999 Vitenberg/Chockler/Keidar/Dolev It relates to support for positionable memberships. In Pacemaker it might be the case that for B to become DC and modify the CIB without A, B would have to STONITH A. If that is the case, then when A gets a new membership including B he can assume that B has not modified the CIB without him. However, I'm not convinced that he can assume that B has received all the same messages during the transition. If Pacemaker clobbers B's CIB after a new membership then it doesn't matter. > > How is the CIB replicated? > Thats not related to the above question is it? > > It is. I'm trying to understand when and how copies of the CIB are synchronized. To that end I've created a simplified graph of crmd's finite state automata using graphviz which others might find useful (attached). I'll try to break this question up: 1. When the CIB is updated, are the none DC copies updated by coping the entire CIB or with a message that represents only the change? 2. Is the update sent to each copy separately or using corosync's multicast? 3. When a new DC is elected, what steps are taken to assure that it's copy of the CIB is up-to-date? For example, a new member that has not finished incorporating the CIB should not be eligible for the role of DC; how is this accomplished. Alan
fsanoterm.dot
Description: Binary data
_______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
