pure-master-slave.xml

<div class="wiki-content maincontent"><h3>Pure Master Slave</h3>

<structured-macro ac:macro-id="0544b78d-ffad-4680-9079-1628602e06d0" ac:name="warning" ac:schema-version="1"><parameter ac:name="title">This feature has been deprecated and will be removed in version 5.8</parameter><rich-text-body>
<p>This feature will be removed in 5.8 as it has not evolved to be production ready. <br clear="none">
You are advised to use <link><page ri:content-title="MasterSlave"></page><link-body>shared storage master/slave</link-body></link> or the <link><page ri:content-title="Replicated LevelDB Store"></page></link>.<br clear="none">
See <a shape="rect" href="https://issues.apache.org/jira/browse/AMQ-4165">AMQ-4165</a></p></rich-text-body></structured-macro>

<p>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. </p>

<h3>How Pure Master Slave works</h3>

<ul><li>A slave of a master broker consumes all message states from the master - messages, acknowledgments and transactional states.<br clear="none">
Whilst a Slave is actively connected to the Master - it does not allow or start any network or transport connectors, it's sole purpose is to duplicate the state of the master.</li></ul>


<ul><li>The master broker will only respond to a client when a message exchange has been successfully passed to the slave. For example, a commit<br clear="none">
in a clients transaction will not complete until the master and the slave have processed the commit.</li></ul>


<ul><li>In the event the master fails (e.g. hardware failure) the slave has optionally two modes of operation
	<ol><li>starts all it's network and transport connectors - allowing clients connected to the master to resume on the slave.</li><li>or can be configured to close down. In this mode, the slave is simply used to duplicate state for the master.</li></ol>
	</li></ul>


<ul><li>clients should use a failover transport for connecting to the master broker first and then the slave. e.g. using a URL such as</li></ul>


<structured-macro ac:macro-id="5658a66f-188d-45ed-bdbd-570413b97b5a" ac:name="code" ac:schema-version="1"><plain-text-body>
failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false
</plain-text-body></structured-macro>
<p>The <strong>randomize</strong> 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</p>

<h3>Limitations of Pure Master Slave</h3>

<ul><li>Only one slave can be connected to the Master</li><li>A failed master cannot be re-introduced without shutting down the the slave broker (no automatic failback)</li><li>There is no automatic synchronization between brokers. This is a manual process.</li></ul>


<h3>Recovering a Pure Master Slave topology</h3>

<p>This is a manual process - once a master has failed, the only sure way to ensure that the toplogy is synchronized again is manually:</p>
<ul><li>shutdown the slave broker (The clients do not need to be shutdown - they will wait until the topology is re-established if they are failover clients</li><li>copy the data directory from the slave over the data directory of the master broker</li><li>re-start the master and the slave</li></ul>


<h3>Configuring Pure Master Slave</h3>

<structured-macro ac:macro-id="05b329fe-8c42-457b-9bd0-892806596141" ac:name="note" ac:schema-version="1"><rich-text-body>
<p>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.</p></rich-text-body></structured-macro>

<p>A master broker doesn't need any special configuration - it's a normal broker until a slave broker attaches itself.<br clear="none">
To identify a broker as a slave - there is just one property to set (see below) as this <a shape="rect" href="http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/broker/ft/slave2.xml">example shows</a> - so configuration is nice and easy:</p>

<structured-macro ac:macro-id="1ecdcc54-02a6-4304-9dde-a99ea9f9f912" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body>
&lt;broker masterConnectorURI="tcp://masterhost:62001" shutdownOnMasterFailure="false"&gt;
  &lt;persistenceAdapter&gt;
      &lt;journaledJDBC journalLogFiles="5" dataDirectory="${activemq.base}/data/broker2" /&gt;
    &lt;/persistenceAdapter&gt;

    &lt;transportConnectors&gt;
	  &lt;transportConnector uri="tcp://slavehost:61616"/&gt;
   &lt;/transportConnectors&gt;
&lt;/broker&gt;
</plain-text-body></structured-macro>

<table><tbody><tr><th colspan="1" rowspan="1"><p> Broker Property </p></th><th colspan="1" rowspan="1"><p> default </p></th><th colspan="1" rowspan="1"><p> Description </p></th></tr><tr><td colspan="1" rowspan="1"><p> masterConnectorURI </p></td><td colspan="1" rowspan="1"><p> null </p></td><td colspan="1" rowspan="1"><p> URI to the master broker e.g. <strong><em>tcp://masterhost:62001</em></strong> </p></td></tr><tr><td colspan="1" rowspan="1"><p> shutdownOnMasterFailure </p></td><td colspan="1" rowspan="1"><p> false </p></td><td colspan="1" rowspan="1"><p> 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. </p></td></tr><tr><td colspan="1" rowspan="1"><p>waitForSlave</p></td><td colspan="1" rowspan="1"><p> false </p></td><td colspan="1" rowspan="1"><p> version 5.2+, if true, a master will wait till a slave has attached before completing its startup sequence</p></td></tr><tr><td colspan="1" rowspan="1"><p>shutdownOnSlaveFailure</p></td><td colspan="1" rowspan="1"><p> false </p></td><td colspan="1" rowspan="1"><p> 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.</p></td></tr></tbody></table>


<h3>Configuring the authentication of the Slave</h3>

<p>In ActiveMQ 4.1 or later you can use a <strong>&lt;masterConnector/&gt;</strong> element as an alternative XML configuration mechanism as shown in the following <a shape="rect" href="http://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/broker/ft/slave2.xml">example</a> to configure the user and password that the slave will use to connect to the master</p>

<structured-macro ac:macro-id="a13054a4-7af8-43ff-8a58-8b9c4611b433" ac:name="code" ac:schema-version="1"><plain-text-body>
&lt;broker brokerName="slave" useJmx="false"  deleteAllMessagesOnStartup="true"  xmlns="http://activemq.apache.org/schema/core"&gt;
    &lt;services&gt;
      &lt;masterConnector remoteURI= "tcp://localhost:62001" userName="James" password="Cheese"/&gt;
    &lt;/services&gt;

    &lt;transportConnectors&gt;
      &lt;transportConnector uri="tcp://localhost:62002"/&gt;
    &lt;/transportConnectors&gt;
  &lt;/broker&gt;
</plain-text-body></structured-macro></div>