activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Smith20 <>
Subject Re: Master/Slave questions
Date Fri, 19 May 2006 16:37:17 GMT

Please see below.



Mathias Herberts wrote:
>>Hi, I am in the process of evaluating ActiveMQ in HA topologies. I am
>>currently doing some tests with the Master/Slave replication and I
>>have a few questions:
>>Can the slave *catch up* if it is started some time after the master?,
>>i.e. master is started at t0 for the first time, slave is started at
>>t0+d also for the first time, will the slave be aware of every message
>>persisted between t0 and t0+d?
> [Eric]  I think the answer is no.
>>If not how can a master and slave be synchronized either at startup or
>>after a communication failure between the two?
> [Eric] There is no way, it seems when Master starts up, it doesn't know
> there will be a Slave, it just go ahead and answer its clients. When a
> Slave comes up, it will register with Master, and the Master start send
> msgs etc. to the Slave. But when there is communcation failure, the Master
> simply drop the Slave and continue its work. The worse part is, when the
> Slave restarts, it can still register with the Master, and work with the
> Master again, but they two are out of sync.
>>I understand that the master will not answer its clients until the
>>operation has been replicated to the slave(s), but since the master is
>>not aware it has slaves until they come up, this whole master/slave
>>replication is rather incomplete, i.e. the master will happily respond
>>to its clients if the slave is not currently connecter, which makes
>>the process rather useless in case of failure since the slave will not
>>have a coherent view of the master's state.
> [Eric] It seems to me the Master/Slave replication is not suitable for
> production environment.
>>What would really be nice would be to have the following commands that
>>could be passed to activemq:
>>- HOLD, freeze the state of the master
>>- FLUSH, flush any data needing to persist to persistent storage,
>>making the persistent storage stable and coherent.
>>this storage could then be replicated (using rsync for file based
>>storage or using DB replication for DB based storage) on any number of
>>- RELEASE, unfreeze the master and resume current operations.
> [Eric] It will be nice if we can have this.
>>Right now I do not see how to set up a secure DR topology ensuring
>>coherent states on the slave.

View this message in context:
Sent from the ActiveMQ - User forum at

View raw message