Kristoffer Gronlund <[email protected]> wrote:
Adam Spiers <[email protected]> writes:
Kristoffer Gronlund <[email protected]> wrote:
Adam Spiers <[email protected]> writes:

- The whole cluster is shut down cleanly.

- The whole cluster is then started up again.  (Side question: what
  happens if the last node to shut down is not the first to start up?
  How will the cluster ensure it has the most recent version of the
  CIB?  Without that, how would it know whether the last man standing
  was shut down cleanly or not?)

This is my opinion, I don't really know what the "official" pacemaker
stance is: There is no such thing as shutting down a cluster cleanly. A
cluster is a process stretching over multiple nodes - if they all shut
down, the process is gone. When you start up again, you effectively have
a completely new cluster.

Sorry, I don't follow you at all here.  When you start the cluster up
again, the cluster config from before the shutdown is still there.
That's very far from being a completely new cluster :-)

You have a new cluster with (possibly fragmented) memories of a previous
life ;)

Well yeah, that's another way of describing it :-)

Yes, exactly.  If the first node to start up was not the last man
standing, the CIB history is effectively being forked.  So how is this
issue avoided?

The only way to bring up a cluster from being completely stopped is to
treat it as creating a completely new cluster. The first node to start
"creates" the cluster and later nodes join that cluster.

That's ignoring the cluster config, which persists even when the
cluster's down.

There could be a command in pacemaker which resets a set of nodes to a
common known state, basically to pick the CIB from one of the nodes as
the survivor and copy that to all of them. But in the end, that's just
the same thing as just picking one node as the first node, and telling
the others to join that one and to discard their configurations. So,
treating it as a new cluster.

OK, so reading between the lines, if we don't want our cluster's
latest config changes accidentally discarded during a complete cluster
reboot, we should ensure that the last man standing is also the first
one booted up - right?

If so, I think that's a perfectly reasonable thing to ask for, but
maybe it should be documented explicitly somewhere?  Apologies if it
is already and I missed it.

_______________________________________________
Users mailing list: [email protected]
http://lists.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

Reply via email to