qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Qpid Java Broker - Master Failure and Recovery
Date Tue, 06 Aug 2013 18:56:41 GMT
Hi James,

I thought you might say that, that's where I was going with that
half-finished sentence originally. I think you have been a bit confused
about the purpose and effect of setting the designatedPrimary attribute.

The designatedPrimary flag only contributes to the behaviour of a node when
it is the only operational node in a 2-node cluster, it doesn't influence
their behaviour when both nodes are operational and can't be used to pick
the master in that case, though it does influence whether a node can elect
itself master when operating by itself. Being designatedPrimary allows a
node to override the need for both nodes to be present to conduct an
election, and also the need for the other node to reply with an
acknowledgement when performing commits etc (if the defined replication
policy requires this normally). This could allow a master to continue
operating if its replica fails, or alternatively allow a former replica to
elect itself master without interaction from the node which has failed.
Without use of the designatedPrimary attribute, these behaviours are
disallowed to ensure both nodes can't assume themselves to be master at the
same time and actually be able to persist changes to the database, i.e a
split-brain scenario.

You can find more information about how all of this works in our
documentation and/or the BDB JE documentation:
http://qpid.apache.org/releases/qpid-0.22/java-broker/book/Java-Broker-High-Availability.html
http://docs.oracle.com/cd/E17277_02/html/ReplicationGuide/lifecycle.html#twonode
http://docs.oracle.com/cd/E17277_02/html/ReplicationGuide/two-node.html

As you noted in a subsequent email there is functionality in BDB's
DbGroupAdmin utilty to transfer the master role, this didn't exist at the
time the prior work on this area was done and so we haven't yet tested it
or exposed that functionality through the JMX MBean for the store, but I
imagine it would be something that gets looked at as part of the work
toward supporting N-node clusters.

Robbie

On 6 August 2013 18:08, jbelch <jamesbelch@verizon.net> wrote:

> Both nodes in the cluster are running.  First node comes up as Master,
> second
> node comes up as Replica.  I was trying to swap the roles with both nodes
> running.  I thought I would be able to tell the master to become the
> replica
> and replica to become the master.  In our production environment, we will
> need to detect the master failure and tell the replica to become the
> master.
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-Master-Failure-and-Recovery-tp7596360p7596564.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message