[ClusterLabs] Pacemaker ordering constraints and resource failures
arvidjaar at gmail.com
Wed Aug 8 17:55:39 UTC 2018
08.08.2018 16:59, Ken Gaillot пишет:
> On Wed, 2018-08-08 at 07:36 +0300, Andrei Borzenkov wrote:
>> 06.08.2018 20:07, Devin A. Bougie пишет:
>>> What is the best way to make sure pacemaker doesn’t attempt to
>>> recover or restart a resource if a resource it depends on is not
>>> For example, we have two dummy resources that simply sleep -
>>> master_sleep and slave_sleep. We then have a non-symmetrical
>>> ordering constraint that ensures master_sleep is started before
>>> start master_sleep then start slave_sleep (kind:Mandatory) (non-
> This constraint tells the cluster to behave in the way you described.
> The "non-symmetrical" parts means that *only* starts are ordered:
> slave_sleep cannot start until master_sleep has been started, but it
> can then run independently, regardless of whether master_sleep stops or
This does not actually answer the question. The question was not why
slave_sleep remained started when master_sleep was stopped, but how
could slave_sleep be (re-)started when master_sleep remained stopped. By
your own words above "slave_sleep cannot start until master_sleep has
been started" and master_sleep remained stopped.
> If you want slave_sleep to also stop whenever master_sleep is stopped,
> then simply leave off the non-symmetrical -- the default behavior is
> what you want. When symmetrical, slave_sleep will be stopped before
> stopping master_sleep (including if master_sleep fails).
No, that was not original question, sorry :)
>>> This works as expected when both resources are disabled. If we
>>> enable slave_sleep first, it won’t actually start until after
>>> master_sleep if enabled and started.
>>> However, if slave_sleep dies when master_sleep is disabled and
>>> stopped, pacemaker recovers and restarts slave_sleep. For example:
>>> - enable master_sleep, and wait for it to start
>>> - enable slave_sleep, and wait for it to start
>>> - disable master_sleep, and wait for it to stop
>> While I can answer your question (although gut feeling is that
>> is expected) - what is your final goal? If I interpret documentation
>> correctly, the configuration with master target state "stop" and
>> target state "start" makes it impossible to start slave at all. So
>> it may be interesting exercise, what are you trying to achieve at the
>>> - kill the slave_sleep process (or, “pcs resource debug-stop
>>> - pacemaker recovers and restarts slave_sleep, even though
>>> master_sleep is disabled and stopped.
>> Actually my first reaction was "why slave was left started when
>> was stopped" :) If you do not question *this*, I'd say this behavior
>> logically correct - pacemaker tries to maintain status quo, and
>> state is "slave running" so it just tries to keep it running.
>> Whether slave should have been stopped when master had been stopped
>> interesting question; documentation is not exactly clear on semantic
>> Mandatory ordering constraints.
>>> Is this the expected behavior, and is there any way to change
>>> it? I’m happy to provide logs if that would help.
>>> Many thanks,
>>> Users mailing list: Users at clusterlabs.org
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratc
>>> Bugs: http://bugs.clusterlabs.org
>> Users mailing list: Users at clusterlabs.org
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.
>> Bugs: http://bugs.clusterlabs.org
More information about the Users