From da7718ef463775acc7d6fbecf2d64c1bbfc39fd8 Mon Sep 17 00:00:00 2001 From: Justin Ross Date: Tue, 19 Apr 2016 23:11:13 +0000 Subject: QPID-7207: Remove files and components that are obsolete or no longer in use; move doc and packaging pieces to the cpp subtree git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1740032 13f79535-47bb-0310-9956-ffa450edef68 --- .../book/src/cpp-broker/HA-Queue-Replication.xml | 126 +++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 qpid/cpp/docs/book/src/cpp-broker/HA-Queue-Replication.xml (limited to 'qpid/cpp/docs/book/src/cpp-broker/HA-Queue-Replication.xml') diff --git a/qpid/cpp/docs/book/src/cpp-broker/HA-Queue-Replication.xml b/qpid/cpp/docs/book/src/cpp-broker/HA-Queue-Replication.xml new file mode 100644 index 0000000000..81b55a3914 --- /dev/null +++ b/qpid/cpp/docs/book/src/cpp-broker/HA-Queue-Replication.xml @@ -0,0 +1,126 @@ + + + +
+ Replicating Queues with the HA module + + As well as support for an active-passive cluster, the + HA module allows you to replicate individual queues, + even if the brokers are not in a cluster. The original + queue is used as normal. The replica queue is + updated automatically as messages are added to or removed from the original + queue. + + + + It is not safe to modify the replica queue + other than via the automatic updates from the original. Adding or removing + messages on the replica queue will make replication inconsistent and may + cause message loss. + The HA module does not enforce + restricted access to the replica queue (as it does in the case of a cluster) + so it is up to the application to ensure the replica is not used until it has + been disconnected from the original. + + +
+ Replicating queues + + To create a replica queue, the HA module must be + loaded on both the original and replica brokers (it is loaded by default.) + You also need to set the configuration option: + + ha-queue-replication=yes + + to enable this feature on a stand-alone broker. It is automatically + enabled for brokers that are part of a cluster. + + + Suppose that myqueue is a queue on + node1 and we want to create a replica of + myqueue on node2 (where both brokers + are using the default AMQP port.) This is accomplished by the command: + + qpid-config --broker=node2 add queue --start-replica node1 myqueue + + If myqueue already exists on the replica + broker you can start replication from the original queue like this: + + qpid-ha replicate -b node2 node1 myqueue + + +
+
+ Replicating queues between clusters + + You can replicate queues between two standalone brokers, between a + standalone broker and a cluster, or between two clusters (see .) For failover in a cluster there are two cases to + consider. + + + + + When the original queue is on the active node + of a cluster, failover is automatic. If the active node + fails, the replication link will automatically reconnect and the + replica will continue to be updated from the new primary. + + + + + When the replica queue is on the active node of a + cluster, there is no automatic failover. However you can use the + following workaround. + + + +
+ Work around for fail-over of replica queue in a cluster + + When a primary broker fails the cluster resource manager calls a script + to promote a backup broker to be the new primary. By default this script + is /etc/init.d/qpidd-primary but you can modify + that in your cluster.conf file (see .) + + + You can modify this script (on each host in your cluster) by adding + commands to create your replica queues just before the broker is + promoted, as indicated in the following exceprt from the script: + +start() { + service qpidd start + echo -n $"Promoting qpid daemon to cluster primary: " + ################################ + #### Add your commands here #### + ################################ + $QPID_HA -b localhost:$QPID_PORT promote + [ "$?" -eq 0 ] && success || failure +} + + Your commands will be run, and your replicas created, whenever + the system fails over to a new primary. + +
+
+
-- cgit v1.2.1