From f160cb6566c17945f7ebc4f3a752b2cc6a051685 Mon Sep 17 00:00:00 2001 From: Robert Gemmell Date: Tue, 5 Jul 2016 21:55:35 +0000 Subject: QPID-7207: remove cpp and python subdirs from svn trunk, they have migrated to their own git repositories git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1751566 13f79535-47bb-0310-9956-ffa450edef68 --- .../book/src/cpp-broker/HA-Queue-Replication.xml | 126 --------------------- 1 file changed, 126 deletions(-) delete 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 deleted file mode 100644 index 81b55a3914..0000000000 --- a/qpid/cpp/docs/book/src/cpp-broker/HA-Queue-Replication.xml +++ /dev/null @@ -1,126 +0,0 @@ - - - -
- 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