RabbitMQ HA: Mirroring VS Pacemaker

[Abu Mohd]

1 - Could anyone elaborate on the differences between these two approaches?
2 - In details what happens to queues and messages if one node fails in each approach?

I see in the docs

Whilst RabbitMQ also supports clustering, clustering is intended to facilitate scalability, not availability. Thus in a cluster, if a node fails, queues which were on the failed node are lost. With the high availability setup described in this guide, when a node fails, the durable queues and the persistent messages within them can be recovered by a different node.

Does this apply to mirrored queues?

[Michael Klishin]

 On 29 March 2016 at 10:57:15, Abu Mohd (ksa...@gmail.com) wrote:
> 1 - Could anyone elaborate on the differences between these two
> approaches?

Please read the docs. The difference is pretty obvious: Pacemaker is a “hot standby” approach.

> 2 - In details what happens to queues and messages if one node fails
> in each approach?

With mirrored queues, a new master for each of them is elected on a mirror that is in sync. In case of Pacemaker,
an entire new node is brought up.

http://www.rabbitmq.com/ha.html
http://www.rabbitmq.com/reliability.html

> I see in the docs
>
> >
> > Whilst RabbitMQ also supports clustering, clustering is intended
> to facilitate scalability, not availability. Thus in a cluster,
> if a node fails, queues which were on the failed node are lost.
> With the high availability setup described in this guide, when
> a node fails, the durable queues and the persistent messages
> within them can be recovered by a different node.
> >
>
>
> Does this apply to mirrored queues?

I believe it only applies to mirrored queues, because mirroring means continuous replication
of messages.
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Bogdan Dobrelya]

Notes inline ...

вівторок, 29 березня 2016 р. 12:35:00 UTC+2 користувач Michael Klishin написав:

 On 29 March 2016 at 10:57:15, Abu Mohd (ksa...@gmail.com) wrote:
> 1 - Could anyone elaborate on the differences between these two  
> approaches?

Please read the docs. The difference is pretty obvious: Pacemaker is a “hot standby” approach.

For Pacemaker, there is also an OCF RA [0] for Active-Active clustering as well, see

"Auto-configuration of a cluster with a Pacemaker". IIRC, the OCF RA script is available with

the rabbitmq-server >=3.5.7 package.

And one may as well specify a custom policy, like expiration or mirroring for queues, with the

/usr/lib/ocf/resource.d/rabbitmq/set_rabbitmq_policy.sh file.

NOTE: for newest rabbitmq-server versions there will be a separate OCF param [1] and an

example file [2] instead.

[0] http://www.rabbitmq.com/pacemaker.html

[1] https://goo.gl/6TCbtp

[2] https://goo.gl/GKgPtj 

 

> 2 - In details what happens to queues and messages if one node fails  
> in each approach?

With mirrored queues, a new master for each of them is elected on a mirror that is in sync. In case of Pacemaker,
an entire new node is brought up.

http://www.rabbitmq.com/ha.html
http://www.rabbitmq.com/reliability.html

The aforementioned OCF RA would pick a running rabbit node with the most uptime since it joined the cluster

and assign it the "Master" role. This has nothing to the queue masters, but is only the join target for nodes when

doing clustering. Queue masters election is out of scope of the OCF RA, the rabbitmq-server handles it instead,

just as Michael described.

So, to summarize things, the OCF RA only cares for the cluster forming, nodes

membership/recovery (including the full mnesia DB erase, when needed!) and picking a "join target" for nodes.

While ensuring mirroring for HA queues, merging conflicts after network partitions and so on is the rabbitmq-server's

app job instead.