Hi,
16.06.2016 14:09, Jan Friesse wrote:
I am pleased to announce the latest maintenance release of Corosync
2.3.6 available immediately from our website at
http://build.clusterlabs.org/corosync/releases/.
[...]
Christine Caulfield (9):
[...]
Add some more RO keys
Is there a strong reason to make quorum.wait_for_all read-only?
In one of products I use the following (fully-automated) actions to
migrate from one-node to two-node setup:
== mark second node "being joined"
* set quorum.wait_for_all to 0 to make cluster function if node is
reboot/power is lost
* set quorum.two_node to 1
* Add second node to corosync.conf
* reload corosync on a first node
* configure fencing in pacemaker (for both nodes)
* copy corosync.{key,conf} to a second node
* enable/start corosync on the second node
* set quorum.wait_for_all to 1
* copy corosync.conf again to a second node
* reload corosync on both nodes
== Only at this point mark second node "joined"
* enable/start pacemaker on a second node
I realize that all is a little bit paranoid, but actually it is handy
when you want to predict any problem you are not aware about yet.
Best regards,
Vladislav
_______________________________________________
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
