You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Ilkka Virolainen <Il...@bitwise.fi> on 2018/08/21 08:06:22 UTC

Artemis - Starting Replicating Slave as Live

Hello,

Is it possible to force a replicating slave of a two-node Artemis cluster to start as live if it cannot connect to the live server in the cluster? Configuring the broker as a master manually every time there is a case that both brokers are shut down and the original master stays offline would be very cumbersome. Not to mention that the configuration changes would then have to be reverted as the situation passes.

Regards,
- Ilkka

Re: Artemis - Starting Replicating Slave as Live

Posted by Justin Bertram <jb...@apache.org>.
No, there is currently no way to force a replicating slave to start as live
if it cannot connect to the live server other than changing the
configuration manually.

The risk in this use-case is if the live broker is actually up but the
network connection between the live and backup cannot be established for
some reason.  If the backup turned itself into a live broker then you'd end
up with a split-brain scenario.

Another risk in this use-case is that the backup doesn't know if it
actually has current data.  The backup could have been down while the live
was still active dispatching and receiving messages.  If the live goes down
and then the backup is restarted it will have stale data and if it became
live could server duplicate messages.

It's really in the hands of the administrators to determine whether or not
the backup should become live or not.  The backup cannot safely make that
determination on its own.


Justin

On Tue, Aug 21, 2018 at 3:06 AM Ilkka Virolainen <
Ilkka.Virolainen@bitwise.fi> wrote:

> Hello,
>
> Is it possible to force a replicating slave of a two-node Artemis cluster
> to start as live if it cannot connect to the live server in the cluster?
> Configuring the broker as a master manually every time there is a case that
> both brokers are shut down and the original master stays offline would be
> very cumbersome. Not to mention that the configuration changes would then
> have to be reverted as the situation passes.
>
> Regards,
> - Ilkka
>