Why a MongoDB replica set matters for a production Graylog cluster
Once Graylog moves beyond a single test node, the question is no longer only where logs are stored but how Graylog keeps its configuration available when a node fails. MongoDB holds Graylog's configuration and metadata, including users, roles, inputs, streams, pipelines, event definitions and dashboards. Log messages do not live there. They are held by the Graylog Data Node or self-managed OpenSearch backend, so MongoDB is small in data volume but critical in function: if it is unavailable, Graylog nodes cannot read or change the settings that govern how logs are processed and searched.
The Graylog multi-node guide recommends three MongoDB nodes running as a replica set for medium to large deployments, alongside three Graylog nodes and a load balancer. A replica set elects one primary for writes and keeps copies on the other members, so the loss of one node does not leave the cluster without a writable configuration store. The three-member pattern also gives a majority for elections. Two members cannot tolerate the loss of one without losing the ability to elect a new primary, which is why a two-node setup does not deliver the protection it appears to. Confirm the exact replica set members and their hostnames in the mongodb_replica_set_name and mongodb_uri settings of each Graylog node before you rely on them.
A single MongoDB instance is usually acceptable for a lab or a proof of concept, where a rebuild from configuration exports is tolerable. It becomes a risk once the cluster is used for production alerting or incident response, because a single instance is a single point of failure for every Graylog node that depends on it. Plan the replica set before go-live rather than after, since converting a standalone instance and changing connection strings on every Graylog node is easier to schedule when the system is not yet in use. Ask your team which maintenance window and recovery expectations apply, and confirm the MongoDB version against Graylog's compatibility matrix for your release.
Run MongoDB on the Graylog nodes or on separate hosts
This table compares placing MongoDB replica members on the Graylog server nodes with running them on dedicated hosts. Read each row as a question to answer for your own environment, since the right choice depends on your ingest volume, search load and team structure. The main takeaway is that co-location is simpler to start but couples failure, patching and capacity, while dedicated hosts cost more to run but separate those concerns.
| Concern | Co-located with Graylog nodes | Dedicated MongoDB hosts |
|---|---|---|
| Resource contention | MongoDB competes with the Graylog server process, journal and search work for CPU, memory and disk, so load spikes can affect both. | MongoDB has its own CPU, memory and disk, so Graylog load does not starve the configuration database. |
| Failure domain | Losing a Graylog node can also remove a replica set member, reducing the quorum margin at the same time as the server role. | A host failure affects one role at a time, and the replica set keeps its three-member layout independent of Graylog node health. |
| Patching and maintenance | Restarting a node for OS or Graylog updates also takes a MongoDB member offline, so maintenance windows must cover both. | Database members can be patched and restarted in their own sequence, with a clear rolling order and health check before moving on. |
| Network exposure of port 27017 | The database port is reachable on the same hosts that serve users and inputs, so firewall rules must keep it limited to Graylog and replica peers. | Hosts can sit on a restricted database network reachable only from Graylog nodes and administrators, which is easier to document for assessors. |
| Ownership of the database tier | Graylog administrators usually own MongoDB operations, backups and upgrades, which fits small teams but mixes responsibilities. | A database or platform team can own MongoDB separately, with its own access controls, backup schedule and change process. |
| Operating cost and effort | Fewer hosts to build, monitor and license, but more careful tuning and change control on shared machines. | More hosts, images and monitoring to maintain, with recurring cost for infrastructure and operations staff. |
| Sizing dependency | Viable when ingest, search concurrency and MongoDB load are modest, which your own load test must confirm. | Better suited when load tests show MongoDB memory or disk needs that compete with Graylog. Confirm host specs from your own test, not from this page. |
How to set up the replica set and point Graylog at it
This sequence turns three MongoDB installs into one replica set with a healthy primary, then points every Graylog node at it with the correct role. The result is a configuration database that survives a single member failure while Graylog keeps its metadata in one consistent place.
Install MongoDB on three members
Install a MongoDB release that the Graylog compatibility matrix lists for your Graylog version. For Graylog 7.0 to 7.2 that means a 7.x release up to 8.2.x, so confirm the exact minor version against the matrix before you install. Use three separate hosts or VMs, ideally in different failure domains, and keep the installs identical. The check is that the mongod service starts cleanly on all three members and reports the same server version.
Configure replica set name and network binding
On each member, set the replication set name in the mongod configuration file and bind the network interface to an address the other members and Graylog nodes can reach, rather than leaving it on localhost only. Enable authentication only after the replica set is working, or follow the MongoDB documentation for keyfile or certificate-based internal authentication from the start. Confirm the exact configuration keys in the MongoDB docs for your release. The check is that each member starts with the replica set option present and listens on its intended address.
Initiate the replica set from the leader member
Choose one member as the initial leader and run the replica set initiation from it, listing its own host and port. Confirm the exact initiation command against the MongoDB documentation for your version before running it. This member becomes the first candidate for primary. The check is that the initiating member reports a replica set status that includes its own entry and a state that is moving toward primary.
Add the two remaining members
From the same member, add the other two hosts as replica set members using their reachable hostnames or IP addresses. Use the names that Graylog nodes will resolve, because clients connect with those addresses. Confirm the member addition steps in the MongoDB documentation. The check is that the replica set configuration lists three members with consistent host names and that no member is flagged as unreachable.
Confirm primary election and member health
Wait for the election to finish, then check the replica set status on every member. You should see exactly one PRIMARY and two SECONDARY members, all reporting healthy, with replication lag close to zero. Test a simple write on the primary and confirm it appears on both secondaries. If no primary is elected, check network reachability between members and the replica set name on each node before going further. The check is one primary, two healthy secondaries and a successful test write that replicates.
Set the Graylog mongodb_uri with the replica set name
On every Graylog server node, set mongodb_uri in the server configuration to a connection string that lists all three MongoDB members and includes the replica set name as a connection option. Confirm the exact connection string format in the Graylog configuration reference and the MongoDB connection documentation. Include credentials and TLS options if you enabled authentication. The check is that each Graylog node starts and logs a successful connection to MongoDB without reporting a replica set mismatch.
Set is_leader to false on follower Graylog nodes
Graylog uses the is_leader setting to decide which node runs leader-only background tasks. Keep is_leader set to true on exactly one Graylog node and set it to false on every other node, as the Graylog multi-node guidance describes. Make the change in each node's server configuration and restart it. The check is that exactly one node reports as the leader in the Graylog system overview, and the web interface and inputs respond from every node.
Which MongoDB versions Graylog 7 supports
The compatibility matrix lists MongoDB 7.x up to 8.2.x as the range supported by Graylog 7.0 to 7.2. Treat that range as the starting point, not the answer. Open the Graylog compatibility matrix and confirm the exact pairing for your Graylog minor version before you choose a MongoDB version. Check the matrix again at the moment you build, because the supported range can change between Graylog releases, and record the version you confirmed in your change ticket.
Pin the MongoDB minor version on every replica set member rather than letting package updates move nodes independently. Members on different minor versions during an incident make failover behavior harder to reason about, and an unplanned upgrade can take a Graylog cluster out of its supported pairing. Set the package manager to hold the MongoDB packages, and make the pinned version part of your configuration management so that a rebuilt node receives the same release as its peers.
Plan each MongoDB upgrade against the Graylog upgrade notes for the target Graylog version, since those notes name the database prerequisites that apply to your path. Rehearse the change on a staging replica set that mirrors production topology, with a restored copy of the Graylog configuration database. Confirm that Graylog servers start, the web interface loads, and inputs and searches behave normally before you upgrade the production primary. Keep the rollback path documented, including the backup you will restore from if the staging run fails.
Authentication, network and access controls for the MongoDB tier
The MongoDB tier holds Graylog configuration, users, roles and metadata, so a weak database boundary exposes the whole log platform. The controls below work together: authentication decides who can connect, network rules decide where connections can come from, and encryption and secret handling protect what travels and what is stored in configuration.
Enable authentication with a dedicated Graylog user
Turn on MongoDB access control and create a database user that holds only the roles Graylog needs on its own database. Graylog nodes then connect with that account instead of an administrator. Before go-live, confirm in the MongoDB access control documentation for your version which built-in roles to grant and whether the user should be scoped to a single database. Test a failed login from a Graylog node to confirm enforcement is active.
Separate admin credentials from the application user
Keep the MongoDB administrator account out of Graylog configuration files and out of day-to-day operations. Administrators use named accounts for maintenance, and the Graylog application user has no rights to create users, change roles or drop databases. Confirm with the MongoDB documentation which role set your operations team needs for backups and replica set changes, and record who holds the administrator credential.
Restrict the database port to known members
Allow traffic to the MongoDB port only from Graylog server nodes and the other replica set members, and block it from user networks, the Data Node tier and the internet. Apply the rule in host firewalls and in any cloud security group or network policy. Confirm the bind address and port settings in your MongoDB configuration so the process does not listen on interfaces you did not intend to expose.
Encrypt member and client traffic with TLS
Enable TLS for connections between replica set members and between Graylog and MongoDB, so credentials and configuration data are not sent in clear text across the network. Plan certificate issuance, distribution and renewal before the cluster goes live, and confirm in the MongoDB TLS documentation which certificate settings apply to your version. Check that the Graylog connection string requests TLS and that certificate validation is not disabled.
Authenticate members with a keyfile or certificates
Replica set members need to trust each other, not only the clients. A keyfile shared across members or member certificates issued by an internal CA provides that trust. Keep the keyfile readable only by the MongoDB service account, rotate it through a planned change, and confirm in the MongoDB internal authentication documentation which option fits your deployment and how to roll out changes without downtime.
Keep the connection string out of plain configuration
The Graylog configuration holds the MongoDB connection string, which includes the database user and password. Store it with restricted file permissions or pass it from a secrets manager at service start, and avoid pasting it into tickets, shared scripts or container images. Confirm in the Graylog installation documentation for your version where the connection setting is read and whether your packaging supports external secret injection.
What to confirm before you rely on a MongoDB replica set
On physical or on-premises hardware, your team owns the disks, the network between the three MongoDB members and the operating system packages. Graylog's multi-node guide recommends MongoDB as a replica set of three nodes, and the question is whether your hardware and network can keep that set healthy under load and during maintenance.
- Storage latency: Ask the MongoDB and Graylog docs what disk performance the database volumes need, then measure fsync and write latency on the actual volumes before go-live.
- Failover under your network: Test what happens when one member is powered off or its link drops, and confirm that an election completes and Graylog reconnects without manual steps.
- OS package support: Check the Graylog compatibility matrix against the MongoDB build you plan to install on your Ubuntu, Red Hat or SUSE release, since package availability varies by distribution.
- Separate or shared nodes: Confirm whether MongoDB shares hosts with Graylog and whether your hardware can absorb both workloads during a node failure.
Confirm each item in writing with your hardware vendor and your own test results, not only with the documentation.
On cloud virtual machines, the provider controls the physical host, so your checks focus on the disk type, the availability zone layout and how instances are replaced. A replica set only protects you if its members do not fail together, so placement matters as much as the MongoDB settings.
- Disk type and IOPS: Confirm that the volume type you choose gives consistent latency for the database files, and check whether the provider throttles it under sustained writes.
- Zone placement: Confirm that the three members run in separate fault domains, and that a zone outage still leaves a voting majority.
- Instance replacement: Check how a failed VM is rebuilt, whether data volumes survive the rebuild, and how long the rejoin takes in your environment.
- Image and package source: Confirm that the OS image and MongoDB packages you use are supported together with the Graylog release you run.
- Network egress and private addressing: Confirm that members reach each other on the private network and that the addresses used in the replica set configuration stay stable.
Run a zone or instance failure test in a non-production copy before you rely on the set.
In Kubernetes or Docker Compose, MongoDB runs as a container with storage, scheduling and restarts managed by the platform. Decide first whether you use a MongoDB operator, a managed external MongoDB service or a hand-built stateful set, because that choice sets who handles initialization, failover and upgrades.
- Operator or external MongoDB: Confirm which MongoDB versions your operator or external service supports for the Graylog release you plan to run, and who applies patches.
- Persistent volumes: Confirm that each member has its own persistent volume, that the storage class delivers the latency you measured, and that volumes survive node drains.
- Replica set initialization: Confirm how the operator or chart runs the initial replica set setup and whether it can be repeated safely after a restart.
- Pod placement and disruption budgets: Confirm that members are spread across nodes and that maintenance cannot evict two members at once.
- Secrets and authentication: Confirm how credentials reach the Graylog and MongoDB containers, and whether keys are rotated without rebuilding the set.
Review the operator or chart documentation for your exact versions, then confirm each point with a failover test.
How MongoDB backups fit into the Graylog restore plan
A replica set protects you from a failed server, but it does not protect you from a bad change. A deleted stream, a wrong role assignment or a faulty bulk update written to the primary is copied to every member within moments, so all members end up holding the same mistake. Treat the replica set as availability and keep a separate, point-in-time backup of the MongoDB data that Graylog uses for configuration and metadata. That covers inputs, streams, pipeline rules, users, roles, dashboards and event definitions, which are often hard to rebuild by hand.
Log data lives in the search backend, either Graylog Data Node or OpenSearch, not in MongoDB. Plan the two restore paths separately. Restoring MongoDB brings back Graylog's configuration, but it does not bring back the indices, and restoring indices does not bring back the streams and rules that route messages into them. Record which index sets your retention and archive commitments depend on, and confirm with the Graylog documentation how index data is backed up and restored for your backend version. Your recovery time and recovery point targets, not the tool you choose, should set how often each backup runs and how long copies are kept. Confirm those targets with the people who own compliance and incident response before you pick a schedule.
A backup you have not restored is an assumption. Restore the MongoDB backup into a staging environment on a schedule, start a Graylog node against it, and check that inputs start, streams route messages, a sample search returns expected results and a login works. Store the Graylog version, the MongoDB version and the Data Node or OpenSearch version with each backup, because a restore into a mismatched version can fail or require an upgrade path you have not planned. Confirm backup tooling, retention periods and encryption requirements against the Graylog installation documentation and the MongoDB operations guidance for your release, and document who is authorized to start a restore.
Questions teams ask before running MongoDB for Graylog
Do I need three MongoDB nodes for Graylog, or can I run one?
Three members is the layout Graylog recommends for medium to large deployments, and it is the safer default. The multi-node guide pairs three Graylog nodes with three MongoDB nodes running as a replica set. A replica set keeps working when one member fails, as long as a majority of its voting members stays up, and it elects a new primary automatically. A single MongoDB instance can serve a lab or short proof of concept, but it holds the configuration and metadata that every Graylog node reads. Its loss stops administration and processing until it is restored. Decide the member count from your recovery expectations, then test a primary failure in staging before go-live.
Can MongoDB run on the same servers as Graylog?
Yes, MongoDB can run on the same hosts as Graylog, but the choice should be deliberate. Co-location reduces the number of machines and can suit small clusters. The cost is shared failure domains: a host fault, a memory spike or a Graylog upgrade can affect both services at once, and patching one layer means touching the other. Separate hosts isolate MongoDB from Graylog's processing load and make maintenance windows easier to plan. Whichever layout you choose, size CPU, memory and disk for each process, keep MongoDB data on storage separate from Graylog's message journal, and confirm the node layout against the current multi-node documentation before ordering hardware.
Which MongoDB versions does Graylog 7.2 support?
For Graylog 7.0 to 7.2, the compatibility matrix lists MongoDB 7.x up to 8.2.x. Graylog 7.2 is the version covered by the current documentation, so it is the reference for a new build. Pick a MongoDB minor version inside that range, then confirm it against the matrix on the day you install, because the matrix is updated as releases are tested. Review the search backend in the same pass. Graylog recommends Data Node, and use of OpenSearch 1.x has been deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Record the exact Graylog, MongoDB and Data Node versions in your change record so later upgrades can be planned against them.
How much effort do the MongoDB build and hardening take?
No single effort figure applies to every environment, so ask for an estimate built from your written scope. The main drivers are the number of hosts and sites, whether MongoDB shares hosts with Graylog, the TLS and authentication design, the backup target and restore testing, monitoring integration, and how many environments must match. Security review adds time when the team must document controls for an assessor or an internal risk committee. Costs fall into one-time work, such as design, build, hardening, testing and documentation, and recurring work, such as patching MongoDB, rotating credentials, running restore drills and applying version upgrades. Ask the partner to show these phases separately in the quote.
What does our team need to provide for a MongoDB build?
Your team provides the decisions and access the build depends on. Expect to supply host access and change windows for each node, network rules between Graylog and MongoDB, DNS names, and the certificate approach, whether that is your own certificate authority or another source. You also need to set the location and retention rules for backups, a secrets store for MongoDB credentials, and named approvers for design decisions. Sizing inputs matter as well: expected daily ingest, retention period and planned growth, which feed storage and journal decisions. Someone must own the platform after handover, including patch intake and on-call contacts. Missing inputs usually cause rework, so list them in the scope before the build starts.
Can our own team build and harden this without a partner?
A capable internal team can build this, provided it has working knowledge of MongoDB administration, Linux operations and Graylog's configuration model. The step most often skipped is testing. Starting a replica set proves little on its own, so failover, restore from backup and Graylog reconnection during a maintenance step all need to be exercised. Build rollback and restore procedures, test them in a non-production environment, and write the run book while the design is fresh. The question to answer honestly is whether the people who will patch MongoDB, respond to alerts and rehearse restores on a regular schedule will have the time to keep doing so. A partner can take on design, build and evidence work under a written scope, then hand over the run book.
What should a partner's quote for this work include?
A useful quote states the scope in terms your team can check. It should list the environments covered, the node count and layout, the MongoDB and Graylog versions, the authentication and TLS design, the backup method and restore test, and the monitoring and alerting setup. It should also name the deliverables, including documentation and handover sessions, along with the client responsibilities and access needs. Look for stated assumptions about sizing and infrastructure, and for explicit exclusions such as hardware procurement or work on Graylog inputs. Ask how scope changes are handled and whether ongoing patching, upgrades and support are priced separately as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen scopes and delivers a MongoDB replica set for Graylog
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the MongoDB replica set that holds Graylog configuration and metadata. Engagements are fixed-scope, so the members, nodes, authentication model, backup targets and handover items are agreed in writing before any work starts.
How we scope
- Confirm the Graylog version and the MongoDB version that the compatibility matrix allows for it.
- Record where each MongoDB member runs, and whether it shares hosts with Graylog servers or sits on separate nodes.
- Agree the authentication model, certificate approach, backup targets and recovery objectives in the written scope.
How we build
- Deploy an odd-numbered replica set on the planned nodes and initialize it from the primary.
- Configure authentication and Graylog connection settings, then verify failover with a planned primary step-down.
- Test backup and restore of the Graylog configuration database on a separate host before go-live.
How we hand over
- Provide a runbook covering member addresses, replica set configuration, credential locations and rotation steps.
- Document the failover test results, backup schedule, restore procedure and the upgrade order for MongoDB and Graylog.
- Walk your operations team through monitoring signals, replication lag checks and the escalation path for a lost majority.
How we support
- Ongoing support, MongoDB upgrades and Graylog upgrade planning are available as a retainer.
- Retainers can cover periodic restore tests, reviews of replica set health and patching within the agreed scope.
- Changes to node count, placement or authentication are quoted against the written scope before work begins.
