qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: A second restart of slave leaves it in catchup state
Date Wed, 22 May 2013 17:59:01 GMT
On 05/06/2013 08:09 AM, Christian Fromme wrote:> Hi Alan,
> On Tue, Apr 30, 2013 at 10:29 PM, Alan Conway <aconway@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 status # Former primary, restarted
>>> joining
>>> $ ./qpid-ha -b 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.


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

View raw message