[rabbitmq-discuss] Shovel configuration for a clustered broker with mirrored high-availability queues

[Eric]

I see that I misunderstood the federated exchange type - you declare
the backing type when you declare the exchange.  For some reason I
thought the backing type was based on the upstream exchanges.

It's still a little odd to me that the master is responsible for
"pulling" rather than having the upstream brokers push.  If I add new
upstream brokers, do I have to edit the master's configuration and
restart it to consume messages from them?

On Jun 29, 9:00 am, Eric wrote:
> Thanks for the reply.
>
> The odd thing about the federation plugin is that the downstream broker,
> which is the 'master' conceptually in my case, has to declare its exchange
> type as 'federation', which means the actual type is based on the upstream
> 'slave' exchange.  That feels strange to me, because I don't want the
> master to really care about the upstream exchange - it's sort of optional.
>  If the upstream broker is alive that's great, and I want it to forward
> messages along to the master.  If it's not, or isn't present when the
> master starts, I don't want that to be a problem.
>
> Maybe I'm not understanding federation correctly?  It just struck me as odd
> that the master has to go declaring all of the upstream sources it expects,
> and the other way (with shovel) seemed more natural.
>
> I understand that the sources and destination fields accept a list for the
> purpose of failover.  I could configure a single shovel that consumes from
> either broker in the 'slave' cluster and publishes to either broker on the
> master cluster, but I'm worried about the shovel's host broker failing and
> taking the shovel down.
>
>
>
>
>
>
>
> On Friday, June 29, 2012 12:31:41 AM UTC-7, Brendan Hay wrote:
>
> > Hi Eric,
>
> > FYI: The 'sources' and 'destinations' configuration fields both accept a
> > list. The shovel plugin doesn't actually pull/push to/from all of these
> > simultaneously, it uses them as a form of simple failover - if a connection
> > fails, it uses the next one in the list.
>
> > It sounds like for your scenario (when clustering in general), it would be
> > easier to use the federation plugin (
> >http://www.rabbitmq.com/federation.html). When you declare a federated
> > exchange on the downstream/master cluster, the plugin auto-magically
> > declares queues (mirrored if configured) on the upstream/AWS cluster .. you
> > would then bind a mirrored queue to the federated exchange on the
> > downstream/master cluster to cause messages to be routed across the link to
> > that queue.
>
> > The plugin will then stay connected even if one of your nodes on either
> > cluster go down .. if the whole downstream/master cluster goes away/down,
> > then messages will pile up in the upstream/AWS queues, and be transfered
> > once the link is re-established.
>
> > Does that solve your use-case?
>
> > Regards,
> > Brendan