Pure Master Slave

A Pure Master Slave configuration provides a basic shared nothing, fully replicated topology which does not depend on a shared file system or shared database.

How Pure Master Slave works


The randomize property just disables randomness so that the transport will always try the master first, then the slave if it can't connect to that. Note that the slave does not accept connections until it becomes the master

Limitations of Pure Master Slave

Recovering a Pure Master Slave topology

This is a manual process - once a master has failed, the only sure way to ensure that the toplogy is synchronized again is manually:

Configuring Pure Master Slave

You should not configure a connection between the master and a slave. The connection is automatically established with the slave's configuration. If you explicitly configure a network connection, you may encounter race conditions when the master broker is under heavy load.

A master broker doesn't need any special configuration - it's a normal broker until a slave broker attaches itself.
To identify a broker as a slave - there is just one property to set (see below) as this example shows - so configuration is nice and easy:

<broker masterConnectorURI="tcp://masterhost:62001" shutdownOnMasterFailure="false">
      <journaledJDBC journalLogFiles="5" dataDirectory="${activemq.base}/data/broker2" />

	  <transportConnector uri="tcp://slavehost:61616"/>
Broker Property default Description
masterConnectorURI null URI to the master broker e.g. tcp://masterhost:62001
shutdownOnMasterFailure false if true, the slave will shut down if the master fails otherwise the slave will take over as being the new master. The slave ensures that there is a separate copy of each message and acknowledgement on another machine which can protect against catastrophic hardware failure. If the master fails you might want the slave to shut down as well as you may always want to duplicate messages to 2 physical locations to prevent message loss on catastrophic data centre or hardware failure. If you would rather the system keep on running after a master failure then leave this flag as false.
waitForSlave false version 5.2+, if true, a master will wait till a slave has attached before completing its startup sequence
shutdownOnSlaveFailure false version 5.2+, if true, a master will shutdown if the slave connection is lost, ensuring that the master will not become out of sync with the slave.

Configuring the authentication of the Slave

In ActiveMQ 4.1 or later you can use a <masterConnector/> element as an aternative XML configuration mechanism as shown in the following example to configure the user and password that the slave will use to connect to the master

  <broker brokerName="slave" useJmx="false"  deleteAllMessagesOnStartup="true"  xmlns="http://activemq.apache.org/schema/core">
      <masterConnector remoteURI= "tcp://localhost:62001" userName="James" password="Cheese"/>

      <transportConnector uri="tcp://localhost:62002"/>