此内容没有您所选择的语言版本。
Chapter 10. High Availability and Failover
After creating a cluster configuration, you can link broker instances together to form high availability (HA) pairs. An HA pair consists of a master broker that serves client requests, and one or more slave brokers that replace the master if it can no longer communicate with clients.
In AMQ Broker 7, a cluster configuration is required for HA. Broker clusters can consist of either a set of non-HA brokers or HA pairs.
AMQ Broker 7 provides the following HA policies:
- Replication
- Replication synchronizes the data between the master and slave brokers over the network. With replication, you can enable failback to return control to the master broker when it comes back online after a failure event and allow clients to fail back to it. You can also create HA groups in which multiple master brokers share one or more slave brokers, and colocate slave brokers in the same JVM as the master broker.
Starting in 7.5, network pinging, which was previously available for use with the replication HA policy, is a deprecated feature. Network pinging cannot protect a broker cluster from network isolation issues that can lead to irrecoverable message loss. This feature will be removed in a future release. Red Hat continues to support existing AMQ Broker deployments that use network pinging. However, Red Hat no longer recommends use of network pinging in new deployments. For guidance on configuring a broker cluster for high availability and to avoid network isolation issues, see Implementing high availability.
- Shared Store
Shared store provides a location for the master and slave brokers to share messaging data. Using a shared store is generally preferable, as it offers the following benefits over replication:
- Performance (shared stores are faster)
- No split-brain issues
Fewer brokers required to maintain quorum (replication requires at least three)
Like with replication, you can enable failback to return control to the master broker after a failure event and allow clients to fail back to it. You can configure multiple slave brokers for a master broker, and colocate slave brokers.
For more information about HA and failover, see Implementing high availability in Configuring AMQ Broker.
10.1. High Availability and Failover Changes
High availability in AMQ Broker 7 differs from AMQ 6 based on how the master is determined and when the broker connections become active.
In AMQ Broker 7, the master and slave roles are fixed. You specify which broker instance is the master, and the slave only becomes active in certain conditions. In AMQ 6, the master and slave roles were not fixed. Instead, the brokers in an HA pair would compete for a lock, and the winner would become the master.
In AMQ Broker 7, in an HA pair, the slave broker’s acceptors are active even if the broker is inactive. In AMQ 6, the slave broker’s transport connectors did not become active until the broker became active.
10.2. How High Availability is Configured
You configure HA by adding an HA policy configuration to the BROKER_INSTANCE_DIR/etc/broker.xml configuration file of each broker.
Example: HA Pair with Shared Store
The master broker is configured like this. By setting failover-on-shutdown to true, the HA pair will fail over to the slave broker if the master broker is shut down:
<configuration>
<core>
...
<ha-policy>
<shared-store>
<master/>
<failover-on-shutdown>true</failover-on-shutdown>
</shared-store>
</ha-policy>
...
</core>
</configuration>
The slave broker is configured like this. By setting failover-on-shutdown to true, this slave broker will become the master if the current master broker is shut down:
<configuration>
<core>
...
<ha-policy>
<shared-store>
<slave/>
<failover-on-shutdown>true</failover-on-shutdown>
</shared-store>
</ha-policy>
...
</core>
</configuration>Related Information
For full details on configuring HA policies, see the following topics in Configuring AMQ Broker:
Revised on 2021-07-26 10:08:13 UTC
