Scaling Graylog to a multi-node cluster

Scaling Graylog from a single node to a multi-node cluster: what the move involves

Moving from one Graylog server to a multi-node cluster means converting the MongoDB instance to a replica set, adding follower Graylog nodes behind a load balancer, and moving log storage to a separate Data Node cluster. Once those pieces are in place, inputs are moved over in a parallel run so that no log source is cut off before the new path is verified. The Graylog multi-node guide recommends three Graylog and MongoDB nodes and three Data Nodes for most medium to large deployments, with the Data Nodes kept on their own cluster, separate from Graylog and MongoDB. The work is not a single configuration change. It touches the database tier, the search tier, the application tier and every input that sends logs, so the effort is driven by how many sources you have and how much of your current setup was built by hand.

The effort depends on the current state of the single node. Check which MongoDB version and search backend are running today, because the compatibility matrix limits which MongoDB and OpenSearch versions work with each Graylog release, and an OpenSearch 1.x backend needs its own upgrade plan before Graylog 8.0. Confirm the target Graylog version against the Graylog installation documentation and the current release line, since the multi-node steps assume a version-specific package layout. Then inventory inputs, streams, pipelines and index sets, because these have to exist on the new nodes or be migrated with them. Ask any partner to base its quote on that inventory and on the number of input sources, not on a generic cluster template.

Expect the work to recur in one place: the cluster needs ongoing monitoring of the journal, the replica set health and the Data Node cluster once it is live, and each Graylog upgrade must be planned across all nodes. Decide early who owns the load balancer DNS record, the http_external_uri setting and the TLS certificates, since those are the first things that break when a cutover goes wrong. A partner quote should separate the one-time build from the support that follows, and state whether the parallel run and rollback are included in the fixed scope.

Which single-node settings carry over to the cluster and which change

This table maps each component of a single-server Graylog deployment to its role in the multi-node cluster. Read the middle column for what carries over unchanged and the last column for what must be set or rebuilt during the move. Confirm edge cases against your own configuration before cutover.

Component	Single-node setup	Multi-node cluster
Graylog server	One server runs the web interface, REST API and processing	Three Graylog nodes share the work, with one leader and two followers where is_leader is false
MongoDB	One instance holds configuration and metadata	Three MongoDB nodes form a replica set, initiated on the leader only
Log storage backend	Search backend runs on the same or a nearby host	Three Data Nodes run on their own cluster, separate from Graylog and MongoDB
Inputs	Inputs are configured and listen on the single server	Inputs are moved so senders reach the load balancer or the intended nodes, and each input is checked on the new node
DNS and external URI	Users and senders reach the server by its host name	A load balancer with a DNS record is encouraged, and http_external_uri is set to that address
Streams, pipelines and index sets	Defined in the database and applied as messages are processed	Usually carry over with the MongoDB data, but confirm that pipeline rules and index sets still match the new Data Node layout
Users, roles and authentication	Stored in MongoDB and used by the single server	Stored in the replica set, so confirm login behavior on every node after failover

Documented tools and config paths for building the cluster

Building the cluster is a configuration exercise, not a migration. The same Graylog and Data Node packages go onto each host, and a small set of settings decides which node leads, how users reach the cluster and where each component finds its peers. The cards below cover the install paths and the settings that must differ between nodes.

Package and Docker Compose installs

Graylog ships as Debian or RPM packages for Ubuntu, Red Hat, SUSE and Debian, and it can also be run with Docker Compose. For a multi-node build, pick one method and use it on every Graylog and MongoDB host so that versions and file layouts match. Confirm the exact package versions for your target release in the installation docs before you pin them, and keep the Docker Compose file for single-host testing separate from production hosts.

Multi-node installation guide

The Ubuntu multi-node guide is the sequence to follow for this build. It covers the three Graylog and MongoDB nodes, the MongoDB replica set and the separate Data Node cluster. Read it against your own host list before you start, and treat the steps as the baseline your change records should reference.

The is_leader setting

In server.conf, is_leader defaults to true, so every node you copy the file to will try to act as leader unless you change it. The leader initiates the MongoDB replica set, and every follower must have is_leader set to false. Check this value on each host after configuration, because a copied file with the wrong value is the most common reason a second node misbehaves.

The http_external_uri setting

http_external_uri must point to the address users and inputs will use, which is the load balancer address backed by a DNS record, not the address of an individual node. Each node still needs its own local bind settings, so set the external URI to the shared name on every node and confirm it resolves from the networks that send logs and open the web interface.

MongoDB URI and replica set settings

The mongodb_uri key on each Graylog node must list every MongoDB member and name the replica set, so a node can still read configuration when one database member is down. Confirm the replica set name matches what you initiate on the leader, and confirm that credentials and TLS options in the URI are the same on all nodes.

Data Node cluster setup

Data Nodes run on their own cluster, separate from the Graylog and MongoDB hosts, and Graylog connects to them as the search backend. Setup is configuration-driven: each Data Node needs its own settings, and the Graylog nodes need to reach them. Confirm the Data Node configuration keys and certificate handling in the current docs for your release, and confirm which edition or license applies to your deployment before you size the cluster.

How leader and follower Graylog nodes divide the work

The leader is the first Graylog node you configure. It is the only node where you initiate the MongoDB replica set, and it is the node that holds the cluster's configuration state while the others join. In the multi-node setup, is_leader defaults to true, so a leader needs no change from the default, but you should still confirm the value in its configuration file before starting it.

MongoDB initiation: Run the replica set initiation on this node only. Running it on followers creates competing sets and leaves the cluster in an inconsistent state.
Configuration file: Confirm is_leader = true and that mongodb_uri lists all three MongoDB members with the replica set name.
Password secret: Use the same password_secret on every Graylog node, or sessions and encrypted settings will fail on followers.
External URI: Set http_external_uri to the load balancer DNS name, not to this node's address.
Data Node connection: Point the node at the Data Node cluster, which must be reachable before the leader starts indexing.

After the leader starts, check that the MongoDB replica set reports a primary and two secondaries, and that the Graylog web interface loads through the leader's own address before any follower joins.

Followers are identical Graylog servers that join the existing cluster and share the work of ingesting, processing and searching logs. Each follower must have is_leader set to false, because the default of true would make it behave as a second leader. Followers do not initiate the MongoDB replica set, and they should not be started until the leader is healthy.

Leader flag: Set is_leader = false in each follower's configuration before its first start.
Shared secrets: Copy the password_secret and the root password hash from the leader exactly, since a mismatch breaks login and node-to-node trust.
MongoDB membership: Confirm each follower can reach all three MongoDB members, and that the member is listed as a secondary, not a separate primary.
Load balancer registration: Add the follower to the load balancer pool only after the node reports healthy in the web interface.
Inputs: Do not create new inputs on a follower. Inputs are moved in the cutover step, after the cluster is verified.

After each follower starts, check the node list in the system overview to confirm the node appears, and send a test message through the load balancer to confirm it is processed.

Before the load balancer sends production traffic to the cluster, every node should pass the same set of checks. This tab covers the gate that applies to the whole cluster rather than to one role. The point of the gate is to find role mistakes, such as two leaders or a follower with the wrong secret, while logs are still going to the original single node.

Role count: Exactly one node has is_leader set to true, and every other node has it set to false.
Replica set state: MongoDB reports one primary and the expected secondaries, with no members stuck in recovery.
Identical configuration: Secrets, time zones and the external URI match across all Graylog nodes.
Load balancer health: Each node passes the load balancer health check on the web and input ports you use.
Test ingest: A test message sent through the load balancer is searchable and visible in every node's view.

Record the output of each check. If any check fails, stop the cutover and keep the original single node receiving logs until the cause is understood.

Each change to a node, whether a restart, a configuration edit or a version update, should be followed by a short verification. This tab describes the sequence that keeps a change from silently breaking the cluster. The sequence matters because a follower that restarts with the wrong settings can look healthy while routing messages incorrectly.

Restart one node at a time: Keep at least one healthy Graylog node in the load balancer pool during any restart.
Confirm the role: After restart, check that the node still has the same is_leader value and still joins the replica set.
Check the journal: Confirm the message journal is not growing after the node rejoins, which would indicate indexing is stalled.
Search a known message: Run a search for a recent, known test message to confirm read access through the load balancer.
Review the audit log: Note the change in your change record with the node name, the time and the person who made it.

If a check fails, pull the node from the pool and investigate before restarting the next node. Confirm the exact health and journal indicators with your Graylog version's documentation.

Sequence for moving from one server to a cluster without losing logs

This sequence takes a running single-server Graylog to three Graylog and MongoDB nodes and three Data Nodes while every log source keeps delivering. Each step ends with a check you can record, so the cutover happens only after the new path has proven it holds the data.

Inventory inputs, sources and index sets
The Graylog administrator lists every input with its type, port, bind address and sending hosts, and records each stream, pipeline, index set and its rotation and retention settings. Map each source to the input it uses so you know exactly which senders must be repointed at cutover. Note which inputs depend on a single listening address, since those need a load balancer or a changed target. The step is done when the inventory is reviewed by the owners of each log source and no input is left unassigned.
Back up MongoDB and current search data
Before any topology change, the platform team takes a MongoDB backup of the Graylog configuration and metadata, and captures the state of the current search backend using its own snapshot or backup method. Store copies outside the server being changed and confirm you can restore them in a test environment. Record the backup time, checksums and restore test result. Ask your Graylog and MongoDB documentation which backup procedure matches your installed versions, and confirm it against the compatibility matrix before relying on it.
Build the Data Node cluster
The infrastructure team installs three Data Nodes on their own cluster, separate from the Graylog and MongoDB hosts, following the Graylog installation guidance for Data Node. The Graylog server connects to this cluster as its search backend, so the new cluster must be healthy before any data moves to it. Confirm the cluster reports green status and that the Data Nodes have the disk sized for your daily ingest multiplied by retention and 120 percent, as Graylog's system architecture guidance advises. The step is complete when a test index can be created, written to and searched.
Convert MongoDB to a replica set on the leader
On the existing server, which acts as the leader, the administrator converts the MongoDB instance to a replica set and initiates it there only, following the Graylog multi-node installation steps. Add the second and third MongoDB members on their hosts and confirm one primary is elected and the members are in sync. Keep the Graylog leader pointed at the replica set connection string. The step is done when the replica set status shows a primary and two healthy secondaries, and the Graylog web interface still loads and shows the same configuration as before.
Add follower nodes with is_leader set to false
The team installs Graylog on two follower hosts and sets is_leader to false in each follower's server.conf, leaving the leader at its default of true. Point the followers at the same MongoDB replica set and the Data Node cluster, and set http_external_uri to the load balancer address so links and API calls resolve correctly. Start each follower and check the logs for successful connection to MongoDB and the search backend. The step is done when all three nodes appear as active in the system overview and only one node is marked leader.
Place the load balancer and DNS record
The network team places a load balancer in front of the three Graylog nodes and creates a DNS record that points to it. Configure health checks on the Graylog web and API port, and for each log input, decide whether senders reach the balancer or the nodes directly, since some protocols such as UDP syslog need explicit balancer support. Confirm the DNS name resolves from the sender networks and that requests to the web interface and API succeed through the balancer. Record which address senders will use for cutover.
Run a parallel period with dual-sending sources
Reconfigure a representative set of log sources so each one sends to both the existing server and the new cluster, or enable the new inputs alongside the old ones. Compare message counts per source, per stream and per index set over a period you agree in advance, and check that parsing, pipeline output and field names match on both paths. Watch the message journal on each node. The journal must hold data while the Graylog server processes or the Data Nodes are slow, so size it at 3 to 5 times daily ingest on SSDs as the system architecture guidance describes. The step is done when counts agree within the tolerance you set and the journal stays below its limits.
Cut over inputs and decommission the old server
Repoint each remaining source to the load balancer address, one group at a time, and keep the old server running and receiving until its traffic has stopped. Verify each group by searching for its messages in the cluster and confirming that no gap appears in timestamps. Once all sources have been stable for the agreed period and the old server's journal is empty, stop its inputs, keep its backups for your retention policy, and then decommission it. The step is done when the new cluster has been the sole receiver, the source-by-source comparison shows no missing ranges, and the old host is retired.

What drives the effort of the cluster move

The effort of moving a single Graylog server onto a three-node Graylog and MongoDB cluster with three Data Nodes is set less by the software steps than by how much existing state must be carried across. The cards below cover the work that scales with your environment, separating one-time build and cutover costs from the infrastructure you keep paying for after go-live.

Inputs and their configuration

Every input on the single server (syslog, GELF, Beats and others) has to be recreated or moved so that it runs on the cluster nodes, with its port, TLS settings and parsing attached. Count inputs by type and note which ones bind to a fixed port on a specific host. Inputs are a one-time rebuild cost, and each one needs a test message before cutover. Ask whether any input depends on a license tier before you plan it.

Log sources to repoint

Every host, network device, application and cloud service that sends logs to the old server address must be pointed at the load balancer or DNS name. This is usually the largest manual task because the sources belong to other teams and change windows differ. Build an inventory of sender, protocol, port and owner before the cutover date. Plan for sources that cannot be reconfigured quickly, since they will keep sending to the old address during the parallel run.

Existing indices and retention

The volume of indices you already hold determines how long data migration or reindexing takes and how much storage the three Data Nodes must provide. Compare current daily ingest, retention days and the sizing rule in Graylog's system architecture guidance, which advises daily ingest times retention days times 120 percent as a planning input. Confirm with the Graylog documentation how index sets and retention are carried across so that old data is not deleted by accident.

Data Node network and certificates

Three Data Nodes on their own cluster need private network paths to the Graylog nodes, open ports between Data Node members, and a certificate authority that issues certificates for each node. Certificate issuance, renewal policy and firewall changes are one-time setup work, but certificate renewal recurs for the life of the cluster. Ask your network team early, because firewall approvals often set the critical path.

MongoDB replica set preparation

Converting the single MongoDB instance into a replica set requires a planned restart, replica set naming, authentication setup and connectivity from all three Graylog nodes. Plan a backup before the conversion and test that the replica set initiates on the leader only. Follower Graylog nodes must have is_leader set to false in their configuration. This is a one-time task, but it touches the configuration database that every node depends on.

Load balancer and DNS changes

A load balancer in front of the three Graylog nodes, with a DNS record, becomes the address users and sources depend on, and http_external_uri must point to it. Health checks, session behavior and TLS termination at the balancer are configured once, but DNS cutover and rollback need a tested plan. Confirm how your load balancer handles web interface sessions before you move users onto it.

Parallel run and recurring infrastructure

Running the old and new servers side by side during cutover doubles monitoring and operator attention for the length of the parallel run, which is a one-time cost you should schedule and staff. After go-live, three Graylog nodes, three Data Nodes and their MongoDB members are recurring infrastructure, along with patching, certificate renewal and upgrade testing. Ask any partner to separate the build quote from the ongoing support and infrastructure estimate.

Questions teams ask before scaling Graylog to a cluster

How much does it cost to scale Graylog from one node to a cluster?

No fixed figure applies to every environment, because cost depends on the work scope and your infrastructure. Graylog Open is free software with no volume limits, so the main costs are the servers, storage, network and people. Expect the one-time costs to be the design, build and cutover work, and the recurring costs to be the extra hosts, storage growth, backups and operations time. Ask any partner for a quote that lists each component separately, including who pays for hardware, licenses and ongoing support. DeployOpen quotes follow from a written scope.

How long does a single-node to multi-node Graylog move take?

Duration depends on how many inputs and log sources you must move, how much stored data needs to stay searchable, and how much change control your organization requires. The work breaks into a MongoDB replica set, follower Graylog nodes, a load balancer, a three-node Data Node cluster, and a staged cutover of inputs. Ask for a timeline in the written scope that shows each stage and the test windows. DeployOpen does not publish durations; the scope and timeline are agreed in writing before work starts.

What must our team provide before a Graylog cluster project starts?

Plan to provide the following before work begins:

Access to the target cloud accounts, data centers or restricted networks where the nodes will run
A list of inputs, log sources and their current volumes and retention needs
Load balancer and DNS decisions, including the external address Graylog will use
Named owners for change approval, backups and on-call response

Confirm the exact sizing inputs with the Graylog system architecture documentation before requesting a quote.

Can our internal team scale Graylog to a cluster without a partner?

Yes, if your team already runs Linux servers, MongoDB and an OpenSearch-class search backend, and has time for a staged cutover. The Graylog multi-node guide describes the steps, but the risks sit in the cutover: losing logs during input moves, misconfigured leader settings, and untested failover. Many teams keep the build in-house and bring in a partner for the design review, cutover rehearsal or post-build hardening. Decide based on your staff capacity and how much log loss or downtime you can accept.

Does a multi-node Graylog cluster need an Enterprise or Security license?

No. Graylog Open supports running Graylog and MongoDB across several nodes and using Data Node as the search backend. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, so review that license with your legal team. Enterprise starts at 15,000 US dollars per year and Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, according to the Graylog pricing page. Some features, such as Okta, OpenID Connect and SAML single sign-on, need Enterprise, so confirm which features your cluster depends on.

How do we confirm the storage and journal sizing for the cluster?

Start with the Graylog system architecture guidance, which advises sizing log storage as daily ingest multiplied by retention days and then multiplied by 120 percent. It also advises giving the message journal 3 to 5 times daily ingest on SSDs. Run these numbers against your measured daily ingest, not an estimate. Then ask any partner to show the calculation, the index rotation settings and the Data Node disk plan in the quote. Validate the result with a load test before cutover.

Which Graylog and backend versions should we target for the cluster?

Pick the version against the compatibility matrix before you plan the build. The current documentation covers version 7.2, and Graylog 7.0 to 7.2 need MongoDB 7.x up to 8.2.x. Graylog recommends Data Node, and OpenSearch 1.x use is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Confirm the exact supported combination in the compatibility matrix and with Graylog before you buy hardware or start the build.

What usually goes wrong during the scale-out and how to prevent it

Most failed scale-outs trace back to a handful of setup steps done out of order or verified too late. The cards below cover the cluster bootstrap, leader flags, client-facing endpoints, backend sizing, the log cutover and the trust and network paths between tiers, with the check that catches each problem before logs depend on it.

MongoDB replica set on the wrong node

The replica set must be initiated once, on the node that is the leader, and only after the other MongoDB members are reachable and configured with the same replica set name. Initiating it on a follower, or initiating it with no followers joined, leaves you with a single-member set that looks healthy but gives no failover. Before adding Graylog followers, confirm with the replica set status output that every member is listed, one primary is elected and the others are secondaries.

Follower left with is_leader true

is_leader defaults to true, so a Graylog node copied from the leader's configuration file without edits will also claim the leader role. Two leaders compete for cluster-wide tasks and can produce duplicate work and confusing behavior in the web interface. Set is_leader to false in the server configuration on every follower, restart each follower, and check the node list in the system overview to confirm exactly one node is marked as leader.

Load balancer pointing at one node

A load balancer whose pool contains only the original server, or a DNS record that still resolves to a single node, hides the new nodes from every client. Users and inputs appear to work while two of three nodes sit idle, and a failure of the one node takes the whole endpoint down. Set http_external_uri to the balancer address, verify the health check hits all three backends, and test by stopping one Graylog node and confirming the web interface and sending log traffic still succeed.

Data Node cluster sized from the wrong ingest figure

Storage sizing uses daily ingest multiplied by retention days and then by 120 percent, so an average taken from a quiet week or a figure measured before new sources were added will undersize the cluster. Peak daily volume and the sources you plan to onboard during the migration period should drive the number, not the current average. Ask for the sizing worksheet to show the ingest figure, retention period and headroom it assumes, and rerun it once the parallel run has measured real volume.

Inputs cut over before the parallel run

Repointing syslog senders, Beats shippers or GELF clients to the new cluster before both paths are verified removes the only copy of logs on the old node while the new path is still untested. Run the old and new inputs in parallel, compare message counts per source and check that parsing pipelines and streams behave the same on the new nodes. Move sources in groups, keep the old input running until the comparison is signed off, and record which sources have been moved.

Journal overflow during cutover

The message journal buffers messages when Graylog nodes or the Data Node cluster cannot keep up, and during a cutover the replica set reconfiguration, input restarts and backlog replay all add load at once. If the journal fills, the oldest unprocessed messages are lost. Size the journal on SSD with several times daily ingest as the planning guide advises, watch journal utilization on every node during the parallel run, and pause the source move if utilization climbs.

Certificate and network gaps between tiers

The Graylog nodes, MongoDB members and Data Node cluster talk to each other on separate ports, and a firewall rule, hostname mismatch or expired certificate on any one path can break indexing while the web interface still loads. Confirm that every node resolves every other node by name, that required ports are open between tiers in both directions and that certificates cover the names the services use. Test each tier-to-tier connection before the first input is moved.

What to check in the first weeks on the cluster

Treat the first weeks after cutover as a comparison exercise. Before you decommission anything, check that the three-node cluster behaves like the single server did. Start with cluster health: confirm that the Graylog nodes see each other, that only the leader runs as leader (is_leader set to false on each follower), and that all three Data Nodes report healthy. Then watch the message journal and output buffers on every Graylog node. A growing journal on one node usually points to uneven input distribution, a slow Data Node, or a load balancer that is not spreading traffic, so compare journal depth against the single-node baseline you recorded before the move.

Next, verify input throughput per node and search correctness. Confirm that each input is running on the nodes you expect and that messages from the same source arrive at the same rate as before. Run a set of saved searches and dashboards that you used on the single server and compare hit counts for the same time ranges. Differences often come from a source still pointing at the old host, a stream or pipeline rule that was not copied across, or an index set that did not rotate as expected. Also confirm that event definitions still fire on test conditions and that notifications reach PagerDuty, Slack or email as configured, because alerting failures are easy to miss when no incident occurs.

Confirm backup and monitoring coverage for MongoDB and Data Node in your own environment, since the cluster adds components that the single server did not have. Check that MongoDB backups run against the replica set and that you can restore them, and that Data Node snapshots or backups match your retention needs. Plan a rollback window before you decommission the single server, and keep it open long enough to see the cluster through a full cycle of your normal reports and alerts. Ask your team to agree in writing what counts as a passed check and who signs off, so that the decision to retire the old host rests on evidence rather than on the absence of complaints.

How DeployOpen scopes and delivers a Graylog cluster build

DeployOpen plans, builds and documents the move from a single Graylog server to a multi-node cluster inside infrastructure you control. Each step is agreed in writing first, then built, tested and handed over so your team can operate the result.

How we scope

We review your current single-node Graylog, MongoDB, log volumes and retention needs before proposing a written scope.
Engagements are fixed-scope, with deliverables, cutover steps and timelines agreed in writing before work starts.
The scope confirms node placement, load balancer choice, DNS naming and how log sources will be moved without loss.

How we build

We convert MongoDB to a replica set, initiate it on the leader and verify membership before adding any follower.
We configure follower Graylog nodes with is_leader set to false and set http_external_uri to the load balancer address.
We build the three-node Data Node cluster separately and test ingest, search and journal behavior under load before cutover.

How we hand over

You receive the as-built configuration, network and DNS records, and a record of each cutover step and rollback point.
Runbooks cover adding nodes, checking replica set health, and moving inputs during maintenance windows.
We walk your operators through monitoring, journal checks and backup procedures so the cluster can be run by your team.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial build is complete.
Retainers can cover Graylog version upgrades, which carry their own documented prerequisites and breaking changes.
We recommend confirming support scope, response expectations and upgrade windows in writing before the retainer starts.