You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Christian Fromme <cf...@strace.org> on 2013/05/06 14:09:46 UTC

Re: A second restart of slave leaves it in catchup state

Hi Alan,

On Tue, Apr 30, 2013 at 10:29 PM, Alan Conway <ac...@redhat.com> wrote:

>> Maybe we have a similar problem with Active/Passive clustering
>> (version 0.20). When I restart the primary, the slave stays in state
>> "ready" and former primary stays in state "joining":
>>
>> $ ./qpid-ha -b 10.40.48.1 status # Former primary, restarted
>> joining
>> $ ./qpid-ha -b 10.40.48.2 status # Former slave, staying in ready state
>> ready
>>
>> Is this expected? I would expect the former slave to become "active"
>> by itself. Maybe I'm mistaken.
>>
>
> Sorry, my previous answer was too hasty. Qpid requires an external agent to
> detect failure of the primary and pick one of the backups to take over.
> Currently you can use cman and rgmanager (from cluster suite) to do this as
> explained in the documentation. If you have another cluster resource manager
> it would be fairly easy to use it instead. The link between rgmanager and
> qpid is just the qpidd-primary script, another manager might also be able to
> use this directly, or a similar script could be written.

Seems like I had my expectations wrong. We actually have a cluster
resource manager that I can use. Thanks!

kaner

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Re: A second restart of slave leaves it in catchup state

Posted by Christian Fromme <ka...@strace.org>.
On Wed, May 22, 2013 at 7:59 PM, Alan Conway <ac...@redhat.com> wrote:

>> Seems like I had my expectations wrong. We actually have a cluster
>> resource manager that I can use. Thanks!
>
> Out of curiosity - what cluster resource manager are you using? I'd be
> interested in hearing about your experience integrating with a different
> manager. Let me know if you need any help with it.

We're using a proprietary cluster resource manager developed by our
company. It integrates quite well with Qpid.

Best,
Christian

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Re: A second restart of slave leaves it in catchup state

Posted by Alan Conway <ac...@redhat.com>.
On 05/06/2013 08:09 AM, Christian Fromme wrote:> Hi Alan,
>
> On Tue, Apr 30, 2013 at 10:29 PM, Alan Conway <ac...@redhat.com> wrote:
>
>>> Maybe we have a similar problem with Active/Passive clustering
>>> (version 0.20). When I restart the primary, the slave stays in state
>>> "ready" and former primary stays in state "joining":
>>>
>>> $ ./qpid-ha -b 10.40.48.1 status # Former primary, restarted
>>> joining
>>> $ ./qpid-ha -b 10.40.48.2 status # Former slave, staying in ready state
>>> ready
>>>
>>> Is this expected? I would expect the former slave to become "active"
>>> by itself. Maybe I'm mistaken.
>>>
>>
>> Sorry, my previous answer was too hasty. Qpid requires an external agent to
>> detect failure of the primary and pick one of the backups to take over.
>> Currently you can use cman and rgmanager (from cluster suite) to do this as
>> explained in the documentation. If you have another cluster resource manager
>> it would be fairly easy to use it instead. The link between rgmanager and
>> qpid is just the qpidd-primary script, another manager might also be able to
>> use this directly, or a similar script could be written.
>
> Seems like I had my expectations wrong. We actually have a cluster
> resource manager that I can use. Thanks!
>

Out of curiosity - what cluster resource manager are you using? I'd be 
interested in hearing about your experience integrating with a different 
manager. Let me know if you need any help with it.

Cheers,
Alan.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org