Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsEMQX clustering connects multiple broker nodes into one deployment so they can distribute client-facing work and coordinate shared state. How that cluster discovers its members, which nodes own persisted data, and how durable-storage replicas are laid out all affect availability. Adding nodes alone does not guarantee a particular uptime or throughput.
What an EMQX cluster does
EMQX describes clustering as its scale-out approach for reliability and availability. Multiple broker nodes operate as a coordinated deployment, distributing client-facing work and cluster state. Actual capacity and failure behavior depend on the architecture, configuration, workload, and failure domains. See EMQX’s Architecture and Design documentation.
How cluster nodes discover each other
Discovery is the mechanism nodes use to find the other members of the cluster; it is separate from replicating data or deciding which nodes own shared state. EMQX Enterprise lists these discovery options:
| Method | What it suits |
|---|---|
| Static node list | A fixed, small setup where node names and addresses are known and stable. |
| UDP multicast | A discovery option listed by EMQX; deployment-specific suitability is not established in the cited comparison. |
| DNS records | Discovery tied to DNS-managed names or records. |
| etcd | Discovery using etcd. |
| Kubernetes service discovery | Discovery integrated with a Kubernetes environment. |
The appropriate choice depends on whether infrastructure is static or changes dynamically. The feature comparison identifies available methods, but does not prescribe a universal best option. See EMQX Feature Comparison.
#1 Best Overall
Core and Replicant: who owns state?
In EMQX’s documented Core/Replicant architecture, the roles are not interchangeable:
- Core nodes persist data and act as the authority for shared cluster state, including routing tables, MQTT client channels, retained messages, cluster configuration, alarms, and Dashboard credentials.
- Replicant nodes are designed to be stateless and do not participate in database operations.
A cluster needs at least one Core node. EMQX’s Kubernetes Operator recommends at least three Core nodes for high availability; that recommendation applies to this documented architecture and does not replace workload-specific resource and failure-tolerance planning. The Operator documentation also shows two Core pods and three Replicant pods as an illustrative configuration, not a standard sizing rule. Its stated minimum memory requests are 512 MiB per Core and 1 GiB per Replicant; Replicants may need more memory when they accept client requests. See Enable Core + Replicant Cluster.
Creating a cluster in Docker Compose
EMQX’s Docker Compose walkthrough is for local testing, not production deployment. It uses static discovery: both nodes have stable names and the same seed-node list. The guide’s example uses EMQX version 6.3.1; check the current documentation before relying on version-specific commands or configuration.
- Set stable node names and a shared seed list. Configure each node with its stable name and make the seed list consistent across the nodes, following the Docker guide.
- Start the local deployment. Run
docker-compose up -dfrom the directory containing the example Compose file. - Verify membership. Run
emqx ctl cluster statusand confirm the expected nodes appear in the cluster status output.
Node names matter beyond discovery: EMQX stores node data under data/mnesia/<node_name>, and the Docker guide warns that changing a node name later can cause data loss. For production deployment, use the deployment guidance rather than treating this local example as a production recipe. See Install EMQX Using Docker.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Deploying Core and Replicant nodes on Kubernetes
The EMQX Operator’s apps.emqx.io/v2 custom resource can set Core and Replicant counts using coreTemplate and replicantTemplate. Its example manifest shows two Core pods and three Replicant pods; those counts illustrate configuration and are not a universal recommendation. Capacity planning must account for the workload and deployment requirements, including the possibility that Replicants need additional resources when handling client requests. Refer to the Operator configuration guide for the manifest and version-specific details.
Plan Durable Storage before initializing it
Durable Storage uses shards replicated across cluster sites. Its documented default replication factor is 3. EMQX advises an odd factor because replica count affects the quorum required for successful writes. More replicas can improve availability, but also increase storage and network overhead. A small cluster may not be able to use the configured factor: for example, a two-node cluster has an effective factor of two.
Choose the initial site count and filesystem
For a multi-node initial deployment, EMQX recommends setting durable_storage.n_sites to the initial cluster size. The default value, 1, is optimized for a single-node cluster and can result in other nodes abandoning their stored data as the cluster forms. Embedded Durable Storage requires a local filesystem on each node; NFS and SMB/CIFS are not supported by the guide’s instructions.
Choose shard count with its long-term cost in mind
Shard count is fixed after initialization. More shards can permit more parallel publishing and consuming, but require additional resources and metadata. Because the layout parameters that establish initial storage cannot be changed after initialization, decide on site count, replication, and shard count before initializing Durable Storage.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPlan for replica movement when nodes change
When sites join or leave, shard-replica responsibilities move between sites. Background transfers can temporarily affect performance. Removing a site can lower the effective replication factor, so EMQX recommends adding a replacement before removing the old site, or making both changes together where possible. See Manage Data Replicas.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How many nodes do you need?
There is no single node count that guarantees a particular capacity or availability level. For the documented Core/Replicant design, EMQX specifies at least one Core node and its Operator recommends at least three Cores for high availability. The number and role of additional nodes depend on client load, resource capacity, desired failure tolerance, storage layout, and deployment environment. Durable Storage’s effective replica count is also constrained by how many sites are available.
EMQX Enterprise’s feature-comparison page lists product claims of up to 100 nodes per cluster, up to 100 million MQTT connections per cluster, 5M+ messages per second, and 1–5 millisecond latency. These are EMQX-published comparison figures; the page does not establish an independent benchmark or state a publication year for them. They should not be treated as a capacity forecast for a particular workload. See Feature Comparison.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
