[rabbitmq-discuss] rabbitmq-ha-test setup

[Brad Knowles]

On Sep 2, 2011, at 1:23 PM, Alexis Richardson wrote:

> Are you saying that mirror-queue management should be exposed
> differently?  If so it might be worth commenting on the thread this
> week where Jason and Matthew and Michael talk about that.

Well, according to the documentation at <http://www.rabbitmq.com/ha.html>, mirrored queues have to be created explicitly within the code:

> Creating a mirrored-queue
> 
> A mirrored-queue must be created as a mirrored-queue. It is not possible to convert a non-mirrored-queue to a mirrored-queue at some later point. It is perfectly acceptable to create a mirrored-queue with no slaves initially, though be aware of the behaviour of adding nodes to a cluster.
> 
> To create a mirrored-queue, you provide an x-ha-policy entry in the argument table presented to queue.declare. The value of this entry is a long string which gives the name of the policy you wish to use for this queue. There are currently two policies available:        
> 
> 	• all: This policy ensures that a mirror of the queue will exist on every node in the cluster. When a new node joins the cluster, a mirror of the queue will be created on the new node. The queue's initial master will be on the node to which the client issuing the queue declare is connected.
> 	• nodes: This policy allows you to specify the exact nodes on which you wish mirrors to exist. To do this, you provide an additional entry in the arguments table, with a key of x-ha-policy-params, and a value which is an array of long strings, each of which is a node name. The queue's initial master will be the first node in the list (and thus this node must exist and be reachable, even if it is not the node to which the client is connected), and slaves are created on the remaining nodes in the list. With this policy, you may declare a mirrored-queue with mirrors on a subset of the nodes in a cluster. You may also declare a mirrored-queue with slaves on nodes which are not currently members of the cluster: when such nodes join the cluster, a slave will automatically be created of the queue on that node. Note however that the mirror on the newly joined node will behave as a new slave. Also note that it is the node-names that must be provided, not host-name or IP address. It is an error to supply an empty array as the value of the x-ha-policy-params entry: the array must contain at least one element.

Personally, I don't want my programmers to have to know anything about the underlying implementation of how HA is provided, all they need to know is that I'm making sure that it's there.  The pacemaker solution is a bit of a kludgey way to do that, IMO.  And I definitely want our failover to be active/active and not active/passive.

If you can point me at the appropriate thread, I will definitely try to make some suitable comments over there.  Thanks!

> That aside, I would urge you to write a round robin exchange ;-)

In the DevOps field, I'm much more of an Ops type than a Dev type.  I can hope to understand some of the underlying infrastructure concepts and how things are logically put together, but I don't hold out much hope that I'll be able to write actual code to do that.

-- 
Brad Knowles <bknowles at ihiji.com>