Shovel and Federation for multi-DC in RabbitMQ - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to declare a shovel that moves messages from source to destination.

RabbitMQ

rabbitmqctl set_parameter shovel my_shovel '{"src-uri": "amqp://", "src-queue": "source_queue", "dest-uri": "amqp://", "dest-queue": "[1]"}'

Drag options to blanks, or click blank then click option'

Atemp_queue

Bdestination_queue

Cbackup_queue

Dsource_queue

Attempts:

3 left

💡 Hint

Common Mistakes

Using the source queue name as the destination queue.

Misspelling the queue name.

The shovel moves messages to the destination_queue, so the destination queue name must be set correctly.

2fill in blank

medium

Complete the command to enable federation plugin in RabbitMQ.

RabbitMQ

rabbitmq-plugins [1] rabbitmq_federation

Drag options to blanks, or click blank then click option'

Astatus

Bdisable

Clist

Denable

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'disable' instead of 'enable'.

Using 'list' which only shows plugins.

To use federation, the rabbitmq_federation plugin must be enabled with enable.

3fill in blank

hard

Fix the error in the federation upstream declaration by completing the missing URI.

RabbitMQ

rabbitmqctl set_parameter federation-upstream my-upstream '{"uri": "[1]", "expires": 3600000}'

Drag options to blanks, or click blank then click option'

Aftp://remote-host

Bhttp://remote-host

Camqp://user:pass@remote-host

Damqp://localhost

Attempts:

3 left

💡 Hint

Common Mistakes

Using HTTP or FTP protocols which are invalid.

Using localhost instead of remote host.

The federation upstream URI must use the AMQP protocol with correct user credentials and remote host.

4fill in blank

hard

Fill both blanks to declare a federation upstream-set with the correct upstream and policy.

RabbitMQ

rabbitmqctl set_parameter federation-upstream-set my-upstream-set '{"upstreams": ["[1]"]}'
rabbitmqctl set_policy federate-me '^fed\.' '{"federation-upstream-set": "[2]"}' --apply-to exchanges

Drag options to blanks, or click blank then click option'

Amy-upstream

Bmy-upstream-set

Cdefault-upstream

Dfederate-me

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing upstream and upstream-set names.

Using policy name instead of upstream-set name.

The upstream-set must include the upstream name my-upstream, and the policy must reference the upstream-set my-upstream-set.

5fill in blank

hard

Fill all three blanks to create a shovel configuration with correct source URI, destination URI, and acknowledgement mode.

RabbitMQ

rabbitmqctl set_parameter shovel my-shovel '{"src-uri": "[1]", "src-queue": "queue1", "dest-uri": "[2]", "dest-queue": "queue2", "ack-mode": "[3]"}'

Drag options to blanks, or click blank then click option'

Aamqp://user:pass@source-dc

Bamqp://user:pass@dest-dc

Con-confirm

Dno-ack

Attempts:

3 left

💡 Hint

Common Mistakes

Swapping source and destination URIs.

Using 'no-ack' which risks message loss.

The shovel needs the correct source URI amqp://user:pass@source-dc, destination URI amqp://user:pass@dest-dc, and the acknowledgement mode on-confirm for reliable delivery.

Practice

1. What is the main purpose of RabbitMQ Shovel in a multi-data center (multi-DC) setup?

easy

A. To encrypt messages within a single RabbitMQ server

B. To share user credentials across multiple RabbitMQ servers

C. To automatically scale RabbitMQ nodes in a cluster

D. To copy messages between queues on different RabbitMQ servers

Solution

1. Step 1: Understand Shovel's role

   Shovel is designed to move or copy messages from one queue to another, even across different RabbitMQ servers.

2. Step 2: Compare options

   Options B, C, and D describe unrelated features like credential sharing, scaling, or encryption, which are not Shovel's purpose.

3. Final Answer:

   To copy messages between queues on different RabbitMQ servers -> Option D

4. Quick Check:

   Shovel copies messages = A [OK]

Hint: Shovel moves messages between queues on different servers [OK]

Common Mistakes:

• Confusing Shovel with Federation
• Thinking Shovel manages user credentials
• Assuming Shovel handles encryption

2. Which of the following is the correct minimal configuration snippet to define a Shovel in RabbitMQ's configuration file?

easy

A. listeners:
amqp:
port: 5672

B. shovels:
my_shovel:
source-uri: amqp://
source-queue: source_queue
destination-uri: amqp://remote
destination-queue: dest_queue

C. clusters:
nodes: [rabbit@node1, rabbit@node2]

D. federation:
upstreams:
my_upstream:
uri: amqp://remote
exchanges: ["my_exchange"]

Solution

1. Step 1: Identify Shovel configuration format

   Shovel config uses 'shovels' key with shovel name and source/destination URIs and queues.

2. Step 2: Match options to Shovel syntax

   shovels: my_shovel: source-uri: amqp:// source-queue: source_queue destination-uri: amqp://remote destination-queue: dest_queue matches the correct syntax for defining a shovel. Options A, B, and C relate to listeners, federation, and clustering, not shovel.

3. Final Answer:

   shovels: my_shovel: source-uri: amqp:// source-queue: source_queue destination-uri: amqp://remote destination-queue: dest_queue -> Option B

4. Quick Check:

   Shovel config starts with 'shovels:' = D [OK]

Hint: Shovel config uses 'shovels:' with source and destination URIs [OK]

Common Mistakes:

• Confusing federation config with shovel config
• Using cluster or listener config for shovel
• Missing source or destination queue keys

3. Given a federation upstream configured to share an exchange named logs from a remote RabbitMQ server, what will happen if a message is published to the local logs exchange?

medium

A. The message will stay local and not be sent to the remote server

B. The message will be forwarded to the remote exchange automatically

C. The message will be received from the remote exchange and appear locally

D. The message will be duplicated on both local and remote exchanges

Solution

1. Step 1: Understand Federation direction

   Federation pulls messages from remote to local, not the other way around.

2. Step 2: Analyze message flow

   Publishing locally to the exchange does not send messages upstream; messages flow from remote to local only.

3. Final Answer:

   The message will stay local and not be sent to the remote server -> Option A

4. Quick Check:

   Federation pulls from remote; local publish stays local = B [OK]

Hint: Federation pulls messages from remote to local, not vice versa [OK]

Common Mistakes:

• Thinking federation pushes messages upstream
• Assuming messages duplicate automatically
• Confusing federation with shovel direction

4. You configured a Shovel to move messages from a local queue to a remote queue, but no messages appear on the remote side. Which is the most likely cause?

medium

A. The Shovel's destination URI is incorrect or unreachable

B. The local queue is empty, so no messages to move

C. The Federation plugin is not enabled on the local server

D. The RabbitMQ server is running in standalone mode

Solution

1. Step 1: Check Shovel connectivity

   If the destination URI is wrong or unreachable, messages cannot be delivered remotely.

2. Step 2: Eliminate other causes

   Local queue being empty means no messages to move, but question implies messages exist. Federation plugin is unrelated to Shovel. Standalone mode does not prevent Shovel operation.

3. Final Answer:

   The Shovel's destination URI is incorrect or unreachable -> Option A

4. Quick Check:

   Shovel needs correct destination URI = A [OK]

Hint: Check destination URI if shovel moves no messages [OK]

Common Mistakes:

• Confusing Federation plugin with Shovel
• Ignoring network or URI errors
• Assuming local queue always has messages

5. In a multi-DC RabbitMQ setup, you want to ensure messages published in any data center are available in all others with minimal delay and no duplicates. Which combination is best?

hard

A. Use only Shovel to copy messages between queues in data centers

B. Use only Federation to share queues between data centers

C. Use Federation to share exchanges and Shovel to copy queues between data centers

D. Use clustering across data centers with mirrored queues

Solution

1. Step 1: Understand Federation and Shovel roles

   Federation shares exchanges or queues, enabling message sharing with minimal delay. Shovel copies messages between queues reliably.

2. Step 2: Combine for best multi-DC setup

   Using Federation for exchange sharing ensures messages are available across DCs. Shovel ensures queues are synchronized, preventing duplicates and delays.

3. Final Answer:

   Use Federation to share exchanges and Shovel to copy queues between data centers -> Option C

4. Quick Check:

   Federation + Shovel = best multi-DC sync [OK]

Hint: Combine Federation for sharing and Shovel for copying queues [OK]

Common Mistakes:

• Relying on clustering across data centers (not recommended)
• Using only one method causing delays or duplicates
• Confusing queue sharing with exchange sharing