LogoLogo
2.1.0
2.1.0
  • Welcome
  • Getting Started
  • Downloads
  • VerneMQ / MQTT Introduction
  • Installing VerneMQ
    • Installing on Debian and Ubuntu
    • Installing on CentOS and RHEL
    • Running VerneMQ using Docker
  • Configuring VerneMQ
    • Introduction
    • The VerneMQ conf file
    • Schema Files
    • Auth using files
    • Auth using a database
    • MQTT Options
    • MQTT Listeners
    • HTTP Listeners
    • Non-standard MQTT options
    • Websockets
    • Logging
    • Consumer session balancing
    • Plugins
    • Shared subscriptions
    • Advanced Options
    • Storage
    • MQTT Bridge
    • REST Publisher
  • VerneMQ Clustering
    • Introduction
    • Inter-node Communication
    • Dealing with Netsplits
  • Live Administration
    • Introduction
    • Inspecting and managing sessions
    • Retained messages
    • Live reconfiguration
    • Managing Listeners
    • Certificate Management
    • HTTP API
    • Tracing
    • Output Format
  • Monitoring
    • Introduction
    • $SYSTree
    • Graphite
    • Netdata
    • Prometheus
    • Health Checker
    • Status Page
  • Plugin Development
    • Introduction
    • Session lifecycle
    • Subscribe Flow
    • Publish Flow
    • Enhanced Auth Flow
    • Erlang Boilerplate
    • Lua Scripting Support
    • Webhooks
  • Misc
    • Loadtesting VerneMQ
    • Not a tuning guide
    • Change Open File Limits
  • Guides
    • A typical VerneMQ deployment
    • VerneMQ on Kubernetes
    • Loadtesting VerneMQ
    • Clustering during development
    • Not a tuning guide
    • Change Open File Limits
    • Migrating to 2.0
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
Export as PDF
  1. Guides

Clustering during development

This describes a quick way to create a VerneMQ cluster on developer's machines

Sometimes you want to have a quick way to test a cluster on your development machine as a VerneMQ developer.

You need to take care of a couple things if you want to run multiple VerneMQ instances on the same machine. There is a make option that let's you build multiple releases, as a commodity, taking care of all the configuration.

First, build a normal release (this is just needed the first time) with:

➜ default git:(master) ✗ make rel

The following command will then prepare 3 correctly configured vernemq.conf files, with different ports for the MQTT listeners etc. It will also build 3 full VerneMQ releases.

➜ default git:(master) ✗ make dev1 dev2 dev3

Check if you have the 3 new releases in the _build directory of your VerneMQ code repo.

You can then start the respective broker instances in 3 terminal windows, by using the respective commands and directory paths. Example:

➜ (_build/dev2/rel/vernemq/bin) ✗ vernemq console

The MQTT listeners will of course be configured differently for each node (the default 1883 port is not used, so that you can still run a default MQTT broker besides your dev nodes). A couple of other ports are also adapted (HTTP status page, cluster communication). The MQTT ports are automically configured in increasing steps of 50: (if in doubt, consult the respective vernemq.conf files)

Node
MQTT listener port

dev1@127.0.0.1

10053

dev2@127.0.0.1

10103

dev3@127.0.0.1

10153

...

...

Note that the dev nodes are not automatically clustered. You still need to manually cluster them with commands like the following:

➜ (_build/dev2/rel/vernemq/bin) ✗ vmq-admin cluster join discovery-node=dev1@127.0.0.1

In case this wasn't clear so far: You can configure an arbitrary number of cluster nodes, from dev1 to devn.

PreviousLoadtesting VerneMQNextNot a tuning guide

Last updated 6 days ago

Was this helpful?