Quantcast

problems with master slave set up artemis 2.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Lei
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

problems with master slave set up artemis 2.0

Lei
I have a master slave non-colocation set up of one master and two slaves.

1. after all three start, only journal replication is only seen on one of the slaves, i.e., the "active" slave.
2. try to simulate the failover scenarios.
scenario A:
- when the master is killed, the "active" slave comes up OK, and the other "passive" slave becomes the "active" slave
- when the original master is restarted, the first "active" slave (the current master) will stay as the live broker even with "allow-failback" set to true
scenario B:
- if the "active" slave was killed first, the secondary/"passive" slave is not able to take over as the "active" slave
- only when the "passive" slave is restarted, it can become the "active" slave to the master.

Is this by design? Or anything wrong with my configuration?

The configurations are attached.

Thanks,
Lei

broker.slave
broker.master
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: problems with master slave set up artemis 2.0

jbertram
> after all three start, only journal replication is only seen on one of the slaves, i.e., the "active" slave.

That's expected.

> when the original master is restarted, the first "active" slave (the current master) will stay as the live broker even with "allow-failback" set to true

That's also expected.

Fail-back doesn't actually occur when multiple backups are configured.  When the 3 broker instances are started there will be 1 live-backup pair and a "left-over" backup will be in a kind of idle state waiting to attach to a suitable live broker.  Then if the live broker instance fails its backup will take over and become live and the other backup will now become the backup of the broker which just became live.  Once the broker instance which failed is restarted it will attempt to register itself as a backup of the now-live broker and initiate fail-back.  However, since the now-live broker already has a backup it will reject the registration message from the original live because it already has a backup, and therefore fail-back will not occur.

> if the "active" slave was killed first, the secondary/"passive" slave is not able to take over as the "active" slave

Can you elaborate on this use-case a bit more? How are you stopping the backup?


Justin

----- Original Message -----
From: "Lei" <[hidden email]>
To: [hidden email]
Sent: Tuesday, May 9, 2017 6:27:44 PM
Subject: problems with master slave set up artemis 2.0

I have a master slave non-colocation set up of one master and two slaves.

1. after all three start, only journal replication is only seen on one of
the slaves, i.e., the "active" slave.
2. try to simulate the failover scenarios.
scenario A:
- when the master is killed, the "active" slave comes up OK, and the other
"passive" slave becomes the "active" slave
- when the original master is restarted, the first "active" slave (the
current master) will stay as the live broker even with "allow-failback" set
to true
scenario B:
- if the "active" slave was killed first, the secondary/"passive" slave is
not able to take over as the "active" slave
- only when the "passive" slave is restarted, it can become the "active"
slave to the master.

Is this by design? Or anything wrong with my configuration?

The configurations are attached.

Thanks,
Lei

broker.slave
<http://activemq.2283324.n4.nabble.com/file/n4725854/broker.slave>  
broker.master
<http://activemq.2283324.n4.nabble.com/file/n4725854/broker.master>  



--
View this message in context: http://activemq.2283324.n4.nabble.com/problems-with-master-slave-set-up-artemis-2-0-tp4725854.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Lei
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: problems with master slave set up artemis 2.0

Lei
Thank you Justin for the reply.

For the third case, i did both kill -9 and normal stop, and the symptom is the same, basically the "idle" backup was not able to become an "active" backup.

For the first two cases, if it is expected behavior, how would we expect the replication delay or even data loss on the "idle" slave when it becomes "active" as it doesn't have any replication going on before its start up, especially in the scenario where the "active" slave fails shortly after the master?


thanks,
Lei
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: problems with master slave set up artemis 2.0

jbertram
Can you outline steps and configuration to reproduce what you're seeing?  An automated reproducer (e.g. based on one of the clustering examples shipped in Artemis) would be best.


Justin

----- Original Message -----
From: "Lei" <[hidden email]>
To: [hidden email]
Sent: Wednesday, May 10, 2017 4:18:35 PM
Subject: Re: problems with master slave set up artemis 2.0

Thank you Justin for the reply.

For the third case, i did both kill -9 and normal stop, and the symptom is
the same, basically the "idle" backup was not able to become an "active"
backup.

For the first two cases, if it is expected behavior, how would we expect the
replication delay or even data loss on the "idle" slave when it becomes
"active" as it doesn't have any replication going on before its start up,
especially in the scenario where the "active" slave fails shortly after the
master?


thanks,
Lei



--
View this message in context: http://activemq.2283324.n4.nabble.com/problems-with-master-slave-set-up-artemis-2-0-tp4725854p4725928.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Loading...