Re: updating cluster.conf on one node, when the other is down

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster

[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux