InfluxDB Enterprise clustering is surprisingly more about managing gossip than data sharding.
Let’s spin up a three-node cluster and watch it go. We’ll need three servers, let’s call them influxdb-01, influxdb-02, and influxdb-03.
First, get InfluxDB Enterprise installed on each node. Grab the latest package from the InfluxData website.
On influxdb-01, we’ll start with a minimal configuration. The key is the cluster-seed setting. This tells the node who to talk to when it first joins the cluster.
[cluster]
# The bind address for cluster communication.
# This is the address that other nodes will use to connect to this node.
# It should be resolvable by all other nodes in the cluster.
bind-address = ":8088"
# The list of seed nodes for the cluster.
# When a node starts, it will try to connect to one of these nodes
# to discover the rest of the cluster.
seed-nodes = ["influxdb-01:8088"]
[http]
# The HTTP bind address for API requests.
# This is the address that clients (like the CLI or Grafana) will connect to.
bind-address = ":8086"
Now, start the InfluxDB service on influxdb-01:
sudo systemctl start influxdb
Check its status:
sudo systemctl status influxdb
You should see it running and not complaining about connectivity.
On influxdb-02, we point it to influxdb-01 as the seed:
[cluster]
bind-address = ":8088"
seed-nodes = ["influxdb-01:8088"]
[http]
bind-address = ":8086"
Start influxdb on influxdb-02 and check its status. It should discover influxdb-01 and join the cluster.
On influxdb-03, we do the same, again pointing to influxdb-01:
[cluster]
bind-address = ":8088"
seed-nodes = ["influxdb-01:8088"]
[http]
bind-address = ":8086"
Start influxdb on influxdb-03. Now all three nodes should be aware of each other.
You can verify this by querying the cluster status from any node using the InfluxDB CLI. Connect to influxdb-01:
influx -host influxdb-01
Then, run:
SHOW SERVERS
You should see all three nodes listed, with their status as active.
The cluster-seed is the initial handshake. Once nodes are connected, they use a gossip protocol to stay in sync. Each node periodically broadcasts its status and listens for updates from others. This is what makes it resilient; if one node goes down, the others continue to communicate and maintain cluster state.
The bind-address in the [cluster] section is crucial. It’s the port all inter-node communication happens on. Ensure this port (default 8088) is open in your firewalls between all nodes. The [http] bind address is for client connections, which is usually on port 8086.
If you wanted to add a fourth node, influxdb-04, you’d configure its seed-nodes to include one of the already running nodes, for example:
[cluster]
bind-address = ":8088"
seed-nodes = ["influxdb-02:8088"] # Could be any of the active nodes
[http]
bind-address = ":8086"
Starting influxdb on influxdb-04 would then allow it to discover the existing cluster via influxdb-02.
One common pitfall is having seed-nodes pointing to an address that isn’t listening or isn’t reachable from the new node. Always ensure the seed node is up and its cluster.bind-address is correctly configured and accessible.
If you add a node and it doesn’t appear in SHOW SERVERS, the most likely cause is a network issue preventing gossip. Double-check firewall rules and bind-address configurations.
The next thing you’ll worry about is how data is distributed across these nodes.