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 >>> started? >>> >>> 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 >>> slave_sleep: >>> start master_sleep then start slave_sleep (kind:Mandatory) (non- >>> symmetrical) > > 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 > fails. >
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 >> behavior >> is expected) - what is your final goal? If I interpret documentation >> correctly, the configuration with master target state "stop" and >> slave >> target state "start" makes it impossible to start slave at all. So >> while >> it may be interesting exercise, what are you trying to achieve at the >> end? >> >>> - kill the slave_sleep process (or, “pcs resource debug-stop >>> slave_sleep”) >>> - 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 >> master >> was stopped" :) If you do not question *this*, I'd say this behavior >> is >> logically correct - pacemaker tries to maintain status quo, and >> target >> state is "slave running" so it just tries to keep it running. >> >> Whether slave should have been stopped when master had been stopped >> is >> interesting question; documentation is not exactly clear on semantic >> of >> 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, >>> Devin >>> >>> >>> >>> _______________________________________________ >>> Users mailing list: [email protected] >>> https://lists.clusterlabs.org/mailman/listinfo/users >>> >>> Project Home: http://www.clusterlabs.org >>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratc >>> h.pdf >>> Bugs: http://bugs.clusterlabs.org >>> >> >> _______________________________________________ >> Users mailing list: [email protected] >> https://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 _______________________________________________ Users mailing list: [email protected] https://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
