[Linux-cluster] updating cluster.conf on one node, when the other is down

Fabio M. Di Nitto fdinitto at redhat.com
Mon Jul 27 06:49:15 UTC 2009


On Fri, 2009-07-24 at 02:35 +0200, Guido Günther wrote:
> Hi,
> taking node2 down, updating the cluster configuration on node1 then
> using "cman_tool version -r 7" on node1 and then booting node2 gives the
> error below:
> 
> corosync[1790]:   [QUORUM] This node is within the primary component and will provide service.
> corosync[1790]:   [QUORUM] Members[1]: 
> corosync[1790]:   [QUORUM]     2 
> corosync[1790]:   [CLM   ] CLM CONFIGURATION CHANGE
> corosync[1790]:   [CLM   ] New Configuration:
> corosync[1790]:   [CLM   ] 	r(0) ip(192.168.122.228) 
> corosync[1790]:   [CLM   ] Members Left:
> corosync[1790]:   [CLM   ] Members Joined:
> corosync[1790]:   [CLM   ] CLM CONFIGURATION CHANGE
> corosync[1790]:   [CLM   ] New Configuration:
> corosync[1790]:   [CLM   ] 	r(0) ip(192.168.122.82) 
> corosync[1790]:   [CLM   ] 	r(0) ip(192.168.122.228) 
> corosync[1790]:   [CLM   ] Members Left:
> corosync[1790]:   [CLM   ] Members Joined:
> corosync[1790]:   [CLM   ] 	r(0) ip(192.168.122.82) 
> corosync[1790]:   [TOTEM ] A processor joined or left the membership and a new membership was formed.
> corosync[1790]:   [CMAN  ] Can't get updated config version 7, config file is version 5.
> corosync[1790]:   [QUORUM] This node is within the primary component and will provide service.
> corosync[1790]:   [QUORUM] Members[1]: 
> corosync[1790]:   [QUORUM]     2 
> corosync[1790]:   [CMAN  ] Node 1 conflict, remote config version id=7, local=5
> corosync[1790]:   [MAIN  ] Completed service synchronization, ready to provide service.
> corosync[1790]:   [CMAN  ] Can't get updated config version 7, config file is version 5.
> 
> Afterwards corosync is spinning with 100% cpu usage. This is cluster
> 3.0.0 with corosync/openais 1.0.0. cluster.conf is attached. Any ideas?

Yes, the configuration sync is now delegated to conga/luci via ccs_sync
or needs to be done manually. The configuration is expected to be
syncronized before cluster startup.

cman will try constantly to reload the config (probably too fast and
that's why you see cpu spinning) till it finds the right version so that
the cluster operations can start again.

I'll check with Chrissie about the spinning.

Fabio




More information about the Linux-cluster mailing list