1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
<?xml version="1.0" encoding="utf-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<section id="ha-queue-replication">
<title>Replicating Queues with the HA module</title>
<para>
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 <firstterm>original</firstterm>
queue is used as normal. The <firstterm>replica</firstterm> queue is
updated automatically as messages are added to or removed from the original
queue.
</para>
<warning>
<para>
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 <emphasis>not</emphasis> 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.
</para>
</warning>
<section>
<title>Replicating queues</title>
<para>
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:
<programlisting>
ha-queue-replication=yes
</programlisting>
to enable this feature on a stand-alone broker. It is automatically
enabled for brokers that are part of a cluster.
</para>
<para>
Suppose that <command>myqueue</command> is a queue on
<command>node1</command> and we want to create a replica of
<command>myqueue</command> on <command>node2</command> (where both brokers
are using the default AMQP port.) This is accomplished by the command:
<programlisting>
qpid-config --broker=node2 add queue --start-replica node1 myqueue
</programlisting>
If <command>myqueue</command> already exists on the replica
broker you can start replication from the original queue like this:
<programlisting>
qpid-ha replicate -b node2 node1 myqueue
</programlisting>
</para>
</section>
<section>
<title>Replicating queues between clusters</title>
<para>
You can replicate queues between two standalone brokers, between a
standalone broker and a cluster, or between two clusters (see <xref
linkend="chapter-ha"/>.) For failover in a cluster there are two cases to
consider.
</para>
<orderedlist>
<listitem>
<para>
When the <emphasis>original</emphasis> 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.
</para>
</listitem>
<listitem>
<para>
When the <emphasis>replica</emphasis> queue is on the active node of a
cluster, there is no automatic failover. However you can use the
following workaround.
</para>
</listitem>
</orderedlist>
<section>
<title>Work around for fail-over of replica queue in a cluster</title>
<para>
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 <filename>/etc/init.d/qpidd-primary</filename> but you can modify
that in your <filename>cluster.conf</filename> file (see <xref
linkend="ha-rm-config"/>.)
</para>
<para>
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:
<programlisting>
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
}
</programlisting>
Your commands will be run, and your replicas created, whenever
the system fails over to a new primary.
</para>
</section>
</section>
</section>
|
