1. Pacemaker will/may call a monitor before starting a resource, in which case
it expects a NOT_RUNNING response. It's just checking assumptions at that point.
2. A resource::start must only return when resource::monitor is successful.
Basically the logic of a start() must follow this:
start()
Hello,
I have a dependency tree starting with PgsqlShared as root, and two sub trees:
1. PgsqlShared->apache->apl->c4fastvpa
2. PgsqlShared->iproute
With the version on Pacemaker that came with SLES11, the starting was done in
parallel, such as
1. PgsqlShared
2. apache and ip
stonith-enabled=false
this might be the issue. The way peer node death is resolved, the surviving
node must call STONITH on the peer. If it’s disabled it might not be able to
resolve the event
Alex
From: alex austin [mailto:alexixa...@gmail.com]
Sent: Wednesday, July 01, 2015 9:51 AM
To: Users@
Hello,
The problem I'm facing: reducing the time between a node panic and the call to
STONITH on the peer node in a two node cluster. Documentation points to the
token value in corosync.conf
totem {
version: 2
secauth: off
threads: 0
token: 1000
token_r
