DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Building a 32-Core Raspberry Pi Cluster From Scratch
  • Use KubeKey To Set Up a Kubernetes and KubeSphere Cluster With NFS Storage
  • One Query, Four GPUs: Tracing a Distributed Training Stall Across Nodes
  • Beyond Fail-Safe: Designing Fail-Operational State Machines for Physical AI

Trending

  • 5 Common Security Pitfalls in Serverless Architectures
  • The Missing `bandit` for AI Agents: How I Built a Static Analyzer for Prompt Injection
  • Building a Spring AI Assistant With MCP Servers: A Step-by-Step Tutorial
  • Identity in Action
  1. DZone
  2. Data Engineering
  3. AI/ML
  4. Creating a RabbitMQ Cluster on a Single Machine

Creating a RabbitMQ Cluster on a Single Machine

Learn more about installing a cluster on a single machine and how to add more nodes to your cluster.

By 
Alex Theedom user avatar
Alex Theedom
·
Aug. 24, 15 · Tutorial
Likes (3)
Comment
Save
Tweet
Share
7.5K Views

Join the DZone community and get the full member experience.

Join For Free

If you are having problems setting up a cluster on a single machine, then the following post might help answer some questions. I assume that you have already set up RabbitMQ on your local machine (rabbit@localhost) and want to know how to add two more nodes and cluster them.

These instructions relate to installation on a MacBook Pro running OS X Yosemite.

As you already have an installation of RabbitMQ. all you need to do is instantiate instances on new nodes. The following command will instantiate an instance of Rabbit on a node called hare@localhost.

    RABBITMQ_NODE_PORT=5674
        RABBITMQ_NODENAME=hare@localhost
        rabbitmq-server &

Ensure the port number is different to the port currently in use.

A sticking point are the ports bound by Rabbit to plug-ins. You might see the following error:

BOOT FAILED
===========

Error description:
 {could_not_start,rabbitmq_mqtt,
    {{shutdown,
      {failed_to_start_child,'rabbit_mqtt_listener_sup_:::1883',
         {shutdown,
            {failed_to_start_child,tcp_listener,
              {cannot_listen,{0,0,0,0,0,0,0,0},1883,eaddrinuse}}}}},
     {rabbit_mqtt,start,[normal,[]]}}}

This means that the Rabbit MQTT for the currently running node is using port 1883.

BOOT FAILED
===========

Error description:
 {could_not_start,rabbitmq_stomp,
    {{shutdown,
        {failed_to_start_child,'rabbit_stomp_listener_sup_:::61613',
           {shutdown,
              {failed_to_start_child,tcp_listener,
         {cannot_listen,{0,0,0,0,0,0,0,0},61613,eaddrinuse}}}}},
     {rabbit_stomp,start,[normal,[]]}}}

This means that the Rabbit STOMP for the currently running node is using port 61613.

To resolve this conflict add an argument to RABBITMQ_SERVER_START_ARGS specifying a new port for the plug-in.

A list of installed plug-in is shown in the RabbitMQ web interface in the overview tab under ports and contexts.

The following shows how to configure ports for the Rabbit management and Rabbit MQTT

RABBITMQ_NODE_PORT=5674
    RABBITMQ_NODENAME=hare@localhost
    RABBITMQ_SERVER_START_ARGS="
        -rabbitmq_management listener [{port,15674}]
        -rabbitmq_mqtt tcp_listeners [1884]"
    rabbitmq-server &

Now add the node to the cluster. Stop the instance, join it to another node and start.

rabbitmqctl -n hare@localhost stop_app
rabbitmqctl -n hare@localhost join_cluster rabbit@localhost
rabbitmqctl -n hare@localhost start_app
cluster Machine

Published at DZone with permission of Alex Theedom. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Building a 32-Core Raspberry Pi Cluster From Scratch
  • Use KubeKey To Set Up a Kubernetes and KubeSphere Cluster With NFS Storage
  • One Query, Four GPUs: Tracing a Distributed Training Stall Across Nodes
  • Beyond Fail-Safe: Designing Fail-Operational State Machines for Physical AI

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook