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 Fri, 10 May 2019 14:46:40 GMT
> 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.

> 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).


Justin

On Fri, May 10, 2019 at 3:24 AM Tim <naveenrazole@gmail.com> wrote:

> Below is the configuration we are using
>
> LIVEA configuration:
>
>     <ha-policy>
>          <replication>
>             <master>
>               <group-name>Node1</group-name>
>                <check-for-live-server>true</check-for-live-server>
>             </master>
>          </replication>
>       </ha-policy>
>
>
> Slave configuration:
>
>
>       <ha-policy>
>          <replication>
>             <slave>
>               <group-name>Node1</group-name>
>                <allow-failback>true</allow-failback>
>             </slave>
>          </replication>
>       </ha-policy>
>
>
> live-backup scenarios working fine... and the data replication working
> absolutely fine if incase of fail-over or bringing back active node again.
>
> only problem I see with the scenarios we are using incase of network
> disruptions or any power failures(like power off scenarios)  as steps
> explained below
>
> Scenario: Power off and On Scenario for HA setup of Artemis
> Step-1: Sent 100 messages and power off Node-1
> Step2: Automatic fail-over to Node-2 and seen all 100 messages in Node-2
> Step3: Sent 100 more messages in Node-2, so it should be total 200 and
> power-off Node-2
> Step-4: Started Node-1 and observe that only 100 messages are available –
> this leads to duplicate of messages and observed the messages published in
> Node-2 are lost.
>
>
>
> Scenario: Network disruption scenario
> Step-1, Published again with 100 messages and performed Network disruption
> Step-2: Messages fail-over to Node-2 and observed 100 messages are present
> in Node-2
> Step-3: Published again with 100 messages on Node-2 and performed Network
> disruption on Node-2
> Step-4: Network disruption resolved on Node-1 and observe that only 100
> messages are available – this leads to duplicate of messages and observed
> the messages published in Node-2 are lost.
>
> As you mentioned you need to configure the server to pull the data back
> from
> live before it became live, Could you please guide me the steps
>
> Please let us know for any questions you have
>
> Thanks for the understanding and reply with answers
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

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