On 7 Apr 2014, at 5:54 pm, Christian Ciach wrote:
> Hello,
>
> I am using Corosync 2.0 with Pacemaker 1.1 on Ubuntu Server 14.04 (daily
> builds until final release).
>
> My problem is as follows: I have a 2-node (plus a quorum-node) cluster to
> manage a multistate-resource. One node should
Have you tried to patch the monitor action of your RA, so that it set the a
temporary constraint location on the node to avoid it becoming master.
Something like
Location loc_splited_cluster -inf: MsRsc:Master $node
Not sure about the above crm syntax, but that's the idea.
Le 8 avr. 2014 02:52,
Well, I guess it would be okay to stop the resource when pacemaker stops,
but the resource should never stop on quorum loss. This is what I wanted to
say.
2014-04-08 2:51 GMT+02:00 Andrew Beekhof :
>
> On 7 Apr 2014, at 5:54 pm, Christian Ciach wrote:
>
> > Hello,
> >
> > I am using Corosync 2.
Interesting idea! I can confirm that this works. So, I need to monitor the
output of "crm_node -q" to check if the current partition has quorum. If
the partition doesn't have quorum, I need to set the location constraint
according to your example. If the partition gets quorum again, I need to
remov
Hello fine folks in Pacemaker land. Hopefully you could share your insight
into this little problem for us.
We have a intermittent problem with failover.
two node cluster
first node power is cut
failover begins to second node
first node reboots
crm_mon -1 on the rebooted node is PENDING (neve
Why did you re-ask the same question as a reply to the first question?
You stonith is still failing.
On 08/04/14 05:24 PM, Campbell, Gene wrote:
Hello fine folks in Pacemaker land. Hopefully you could share your insight
into this little problem for us.
We have a intermittent problem with fa
Yeah, sorry, been a long day. Basically, I replied to this question, so I
could reuse the ML address, but then intended to change the subject. I
figured it made no sense as a post to this thread, so I resent the way I
had intended.
Sorry for the confusion. Hopefully these messages will settle.
On 08/04/14 10:31 PM, Campbell, Gene wrote:
Yeah, sorry, been a long day. Basically, I replied to this question, so I
could reuse the ML address, but then intended to change the subject. I
figured it made no sense as a post to this thread, so I resent the way I
had intended.
Sorry for the conf
I don't really like the idea to periodically poll "crm_node -q" for the
current quorum state. No matter how frequently the monitor-function gets
called, there will always be a small time frame where both nodes will be in
the master state at the same time.
Is there a way to get a notification to th
Le 10 avr. 2014 15:44, "Christian Ciach" a écrit :
>
> I don't really like the idea to periodically poll "crm_node -q" for the
current quorum state. No matter how frequently the monitor-function gets
called, there will always be a small time frame where both nodes will be in
the master state at th
Thank you for pointing me to the environment variables. Unfortunately, none
of these work in this case. For example: Assume one node is currently the
master. Then, because of a network failure, this node loses quorum. Because
"no-quorum-policy" is set to "ignore", this node will keep being a master
On Fri, Apr 11, 2014 at 10:02:59AM +0200, Christian Ciach wrote:
> Thank you for pointing me to the environment variables. Unfortunately, none
> of these work in this case. For example: Assume one node is currently the
> master. Then, because of a network failure, this node loses quorum. Because
>
Thank your for another idea, but I think I will pass ;)
I would like to use booth, but as I said, I also need location constraints
based on an attribute-score (like ping). I don't think this is currently
possible when using a multi-site-cluster.
2014-04-11 15:05 GMT+02:00 Lars Ellenberg :
> On
I am sorry to get back to this topic, but I'm genuinely curious:
Why is "demote" an option for the ticket "loss-policy" for
multi-site-clusters but not for the normal "no-quorum-policy" of local
clusters? This seems like a missing feature to me.
Best regards
Christian
2014-04-07 9:54 GMT+02:00
On 26 May 2014, at 10:47 pm, Christian Ciach wrote:
> I am sorry to get back to this topic, but I'm genuinely curious:
>
> Why is "demote" an option for the ticket "loss-policy" for
> multi-site-clusters but not for the normal "no-quorum-policy" of local
> clusters? This seems like a missing
On 05/27/14 08:07, Andrew Beekhof wrote:
>
> On 26 May 2014, at 10:47 pm, Christian Ciach wrote:
>
>> I am sorry to get back to this topic, but I'm genuinely curious:
>>
>> Why is "demote" an option for the ticket "loss-policy" for
>> multi-site-clusters but not for the normal "no-quorum-policy
On 27 May 2014, at 3:12 pm, Gao,Yan wrote:
> On 05/27/14 08:07, Andrew Beekhof wrote:
>>
>> On 26 May 2014, at 10:47 pm, Christian Ciach wrote:
>>
>>> I am sorry to get back to this topic, but I'm genuinely curious:
>>>
>>> Why is "demote" an option for the ticket "loss-policy" for
>>> mult
On 05/27/14 13:34, Andrew Beekhof wrote:
>
> On 27 May 2014, at 3:12 pm, Gao,Yan wrote:
>
>> On 05/27/14 08:07, Andrew Beekhof wrote:
>>>
>>> On 26 May 2014, at 10:47 pm, Christian Ciach wrote:
>>>
I am sorry to get back to this topic, but I'm genuinely curious:
Why is "demote" a
2014-05-27 7:34 GMT+02:00 Andrew Beekhof :
>
> On 27 May 2014, at 3:12 pm, Gao,Yan wrote:
>
> > On 05/27/14 08:07, Andrew Beekhof wrote:
> >>
> >> On 26 May 2014, at 10:47 pm, Christian Ciach
> wrote:
> >>
> >>> I am sorry to get back to this topic, but I'm genuinely curious:
> >>>
> >>> Why is
On 27 May 2014, at 7:20 pm, Christian Ciach wrote:
>
>
>
> 2014-05-27 7:34 GMT+02:00 Andrew Beekhof :
>
> On 27 May 2014, at 3:12 pm, Gao,Yan wrote:
>
> > On 05/27/14 08:07, Andrew Beekhof wrote:
> >>
> >> On 26 May 2014, at 10:47 pm, Christian Ciach wrote:
> >>
> >>> I am sorry to get ba
Done:
http://bugs.clusterlabs.org/show_bug.cgi?id=5216
Best regards,
Christianc
2014-05-27 22:51 GMT+02:00 Andrew Beekhof :
>
> On 27 May 2014, at 7:20 pm, Christian Ciach wrote:
>
> >
> >
> >
> > 2014-05-27 7:34 GMT+02:00 Andrew Beekhof :
> >
> > On 27 May 2014, at 3:12 pm, Gao,Yan wrote:
>
21 matches
Mail list logo
