A master/slave failover pattern consists of a cluster of brokers where one broker (the master) is currently active and one or more brokers (the slaves) are on hot standby, ready to take over whenever the master fails or shuts down. Note that a master/slave cluster is not the same thing as a network of brokers. The brokers in a master/slave cluster are never linked using a network connector.
Table 4 provides an overview and comparison of the different master/slave patterns supported in Fuse Message Broker.
Table 4. Master/Slave Patterns
| Pattern | Requirements | Advantages | Disadvantages |
|---|---|---|---|
| Pure master/slave | None | No central point of failure. | Requires manual restart. Only one slave supported. |
| Shared file system master/slave | A shared file system. | Unlimited number of slaves. Automatic recovery of old masters. | None |
| JDBC master/slave | A shared database. | Unlimited number of slaves. Automatic recovery of old masters. | Cannot use high performance journal. |
Assuming that you choose the mode of operation where the slave takes over from the
master, your clients will need to include logic for failing over to the new master.
Adding this logic to clients is easy. You set them up to connect to the cluster using
the failover protocol which has built in reconnect logic. For example, assuming that the
master is configured to accept client connections on tcp://masterhost:61616,
and the slave is configured accept client connections on
tcp://slavehost:61616, you would use the failover URL shown in
Example 10 for your clients.
Example 10. Failover URL for Connecting to a Master/Slave Cluster
failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false
Setting the randomize option to false ensures that the
failover URL tries to connect to the master before the slave. This can speed up the
initial connections in pure master/slave set ups.
For more information on using the failover protocol see Failover Protocol in Broker Client Connectivity Guide.
 |  |  |
 |
