activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <jbert...@apache.org>
Subject Re: Reg Artemis power and network disruption scenarios
Date Sun, 12 May 2019 01:17:47 GMT
> Here In this case, if the complete server is down and it is not
recoverable, how will we recover such scenarios?

I'm not quite sure what you're asking here. You say "it is not recoverable"
and then ask how you can recover it. This is a contradiction. If it is not
recoverable then you can't recover. Please clarify what you mean.


> Here network disruption means, we tried by removing the ethernet option
in linux environment. so, even in this case we should bring up the broker
which uses the the most up-to-date data  by looking at the logs?? by
bringing up the network.

In this case it sounds like you're inducing a split brain (which I
described in my previous email) by severing the network connection between
the live and the backup. Since you only have a single live/backup pair
there's no quorum voting so no good way to mitigate this problem. This is
why we recommend 3 live/backup pairs or using shared-store.


> having 3 live/backup pairs(so, it means 6 brokers in 6 different servers)
will be a heavy solution for us.

You'll have to weigh that against the integrity of your data. There are
pros and cons to every solution. You could always use shared-store with a
single live/backup pair.


Justin

On Sat, May 11, 2019 at 1:23 AM Tim <naveenrazole@gmail.com> wrote:

> Thanks for the explanation, please find my comments below and please help
>
> Scenario: Power off and On Scenario for HA setup of Artemis
>
> The behavior you're seeing is the expected behavior in this use-case since
> you're using replication. In step 3 when you power-off Node-2 there is now
> no broker online with those 100 messages you just sent. When you restart
> Node-1 it has no way of knowing those 100 messages even exist since they
> were produced when it was offline and the broker that owns them is offline
> as well. If you ever find yourself in a situation where you're using
> replication and both your master and slave are offline you need to examine
> the logs to see which was active most recently as that will tell you which
> node has the most up-to-date data. Then you should start that node first.
> If it's the slave then you'll need to change the configuration to be live
> so that it will actually start all the way rather than waiting for its
> live
> broker to start.
>
> What I see is only way to recover the messages is to verify the logs which
> are most up-to-date data and needs to start the node.
>
> Here In this case, if the complete server is down and it is not
> recoverable,
> how will we recover such scenarios?
>
> > Scenario: Network disruption scenario
>
> You'll need to describe a bit more about what you mean by "network
> disruption" here.
>
> In general, it's important to note that running a single live/backup pair
> using replication is *not recommended* due to the risk of split-brain
> (i.e.
> a situation where both the live and the backup become active at the same
> time due to a loss of connectivity between the live and the backup). It's
> recommended that you use 3 live/backup pairs (so that they can perform
> quorum voting to mitigate split-brain) or shared-storage (where the locks
> on the journal on the shared storage device prevents the live and the
> backup from running simultaneously).
>
> Here network disruption means, we tried by removing the ethernet option in
> linux environment. so, even in this case we should bring up the broker
> which
> uses the the most up-to-date data
> by looking at the logs?? by bringing up the network.
>
> having 3 live/backup pairs(so, it means 6 brokers in 6 different servers)
> will be a heavy solution
> for us.
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

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