On 09/02/2011 12:59 AM, Vladislav Bogdanov wrote: > Hi all, > > I'm trying to further investigate problem I described at > https://www.redhat.com/archives/cluster-devel/2011-August/msg00133.html > > The main problem for me there is that pacemaker first sees transitional > membership with left nodes, then it sees stable membership with that > nodes returned back, and does nothing about that. On the other hand, > dlm_controld sees CPG_REASON_NODEDOWN events on CPGs related to all its > lockspaces (at the same time with transitional membership change) and > stops kernel part of each lockspace until whole cluster is rebooted (or > until some other recovery procedure which unfortunately does not happen
I believe fenced should reboot the node, but only if there is quorum. It is possible your cluster has lost quorum during this series of events. I have copied Dave for his feedback on this point. > :( ). It neither requests to fence left node nor recovers when node is > returned on next stable membership. > > Could anyone please help me to understand, what is a correct CPG > behavior on membership change? > From what I see, CPG emits CPG_REASON_NODEDOWN event on both > transitional and stable membership if there is node which left the > cluster. Am I correct here? And is that a right thing if I am? > Line #'s where this happens? > If yes, is there a way do detect membership change type (transitional pr > stable) through CPG API? > A transitional membership will always contain a subset of the previous regular membership. This means it will always contains 0 or more left members. A transitional membership means "The membership of nodes transitioning from previous regular membership to new regular mebmership". A regular configuration is where members are added to the configuration when detected. A transitional membership never has nodes added to it. > Hoping for answer, > It would be nice if cpg and totem had a direct relationship in how their transitional and regular configurations were generated, but this doesn't happen currently. I am not sure if there is a good reason for this. Regards -steve > Best regards, > Vladislav > _______________________________________________ > Openais mailing list > Openais@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
