How To Install MongoDB on Ubuntu

By Mark Drake and Manikandan Kurup MongoDB is one of the most popular open-source NoSQL databases, widely used for applications that require flexible data structures, high scalability, and fast performance. It stores data in a document-oriented format using JSON-like objects, which makes it ideal for modern web, mobile, and analytics workloads. Developers favor MongoDB for its dynamic schema, automatic sharding, and built-in replication features that support both horizontal scaling and high availability. When combined with the stability and security of Ubuntu, MongoDB provides a strong foundation for running reliable and efficient database-driven applications. In this article, we explain how to install, configure, and maintain MongoDB 8.2 on Ubuntu 24.04 LTS. We cover every essential step, from preparing the server and enabling security features to optimizing performance, setting up replication and backups, and troubleshooting common issues. By the end, you will have a production-ready MongoDB deployment that is properly secured, monitored, and tuned for long-term use. Whether you are setting up MongoDB for development, testing, or a full production environment, this guide provides the detailed instructions and operational best practices needed to run it effectively. To follow this tutorial, you will need: Ubuntu 24.04 includes a version of MongoDB in its default package repositories, but it’s usually outdated. For production systems, you should always install MongoDB directly from the official MongoDB repository. This ensures you get the latest stable version (8.2 at the time of writing) along with timely security and maintenance updates. Let’s add the MongoDB repository to your system’s APT sources, import the GPG key used to verify packages, and then install the database. APT uses GPG keys to verify the authenticity of packages. Without this, your system won’t trust MongoDB’s repository. Run the following command to import the public key for MongoDB 8.0: Here’s what this does: If the command completes without errors, the key has been successfully added. Next, create a new repository list file that points to MongoDB’s official package source for Ubuntu 24.04 (“Noble”). Each part of this command serves a clear purpose: After adding a new repository, you must refresh your system’s local list of available packages so APT recognizes the new source: APT will download the latest package lists and verify them using the GPG key. If you see MongoDB listed among the repositories, your configuration is correct. Now install MongoDB and its associated tools: The -y flag automatically confirms the installation prompts. This will install a set of related packages, including: Once installed, the binaries are placed under /usr/bin/, and configuration files are located in /etc/mongod.conf. You can verify that MongoDB 8.2 was installed successfully by checking its version: You should see an output similar to: If you see this, MongoDB is installed correctly and ready to be started as a service. When you install MongoDB on Ubuntu, the package automatically includes a systemd service unit named mongod.service. This integration allows MongoDB to start, stop, and restart cleanly using Ubuntu’s standard service management commands, just like Nginx, PostgreSQL, or any other major daemon. By default, MongoDB doesn’t start automatically after installation. To launch it manually, use the following command: If the command runs without error, the service should now be active. You can confirm with: The line “Active: active (running)” confirms the database is up and functioning. If you instead see “failed” or “inactive”, skip ahead to the Checking MongoDB Logs section to troubleshoot. Most production systems require the database to start automatically after a reboot. To enable MongoDB to launch on boot, run: This creates a symbolic link in /etc/systemd/system/multi-user.target.wants/, telling systemd to start the service automatically whenever the system enters multi-user mode (the standard operating mode for servers). You can confirm the change with: If you ever want to disable automatic startup (for maintenance or testing), use: Once MongoDB is running, it’s a good idea to confirm it’s responding properly. Run the following command to connect to the database and check its connection status: A value of "ok": 1 confirms the server is working correctly and accepting connections on port 27017. Once you’ve verified MongoDB is running, it’s helpful to know how to manage it safely in day-to-day operations. Here are the key commands: Restarting the service (restart) is particularly important after editing /etc/mongod.conf. This ensures your configuration changes are loaded. If MongoDB fails to start or behaves unexpectedly, your first troubleshooting step should be checking the logs. MongoDB logs are located at: You can view the last 20 lines with: Common log messages include: You can also use journalctl to view service-specific logs managed by systemd: It’s good practice to verify that MongoDB starts automatically after a reboot, especially before deploying applications. After your server restarts, log back in and check the service: If it shows “active (running)”, your configuration is correct and persistent. When you install MongoDB, its behavior is controlled by a single configuration file located at /etc/mongod.conf. This file defines how MongoDB runs: everything from where it stores data, to how it logs activity, which IP addresses it listens on, and what security mechanisms are active. Understanding this file is critical, especially if you plan to run MongoDB in production. Settings in this file are equivalent to corresponding command-line options, but using a configuration file makes server management simpler, especially for larger or automated deployments. MongoDB’s configuration file uses YAML syntax, which is indentation-sensitive. That means you must use spaces (not tabs) when editing it, even one misplaced space can break the configuration. You can view the file’s current contents with: The default file looks something like this: Let’s break this down section by section. This section defines where MongoDB stores its data and how it manages journaling (which ensures data durability). dbPath: This is the directory where MongoDB stores its databases, collections, and indexes. By default, it points to /var/lib/mongodb. If you change this path, make sure the directory exists and is owned by the mongodb user: journal.enabled: When set to true, MongoDB maintains a journal file that helps recover from crashes or unexpected shutdowns. Journaling writes changes to a separate log before committing them to the data files, preventing corruption. Always keep this enabled for production systems. Tip: With WiredTiger, separating the journal onto another disk generally does not improve performance. This optimization was relevant for older storage engines but is no longer recommended. This controls how and where MongoDB writes its logs. You can view logs directly with: If your logs grow too large, consider enabling log rotation with a tool like logrotate or configuring your system logs to rotate automatically. This section defines how MongoDB listens for incoming network connections. By default, it’s limited to 127.0.0.1 (the local loopback address), meaning only local connections are accepted. This is a critical security default that prevents remote access until you explicitly allow it. If you plan to connect from another machine (for example, a web server or remote application), you can modify it as: Or, to listen on all interfaces (use cautiously in production): Security Note: If you enable remote access, always enable authentication and firewall rules to restrict which IPs can connect. MongoDB installs with authentication disabled by default. Anyone who can connect to the database can read or modify data. That’s fine for testing, but a security threat for any real system. To enable user-based authentication, add the following section: Once this is enabled, MongoDB will require users to authenticate with a username and password before performing operations. You’ll configure authentication in detail in the Securing MongoDB section. Other optional settings in this section include: This section controls how MongoDB handles process management and runtime information. This is mostly informational; it ensures that MongoDB has access to timezone data for timestamp conversions. In advanced deployments, you can also enable forking here (for background operation) if MongoDB is started manually without systemd. You won’t see these sections in a fresh installation, but they’re used in multi-node or distributed setups. Example for enabling a replica set: This tells MongoDB to start as part of a replica set named rs0. You’d then initialize and add members from within the MongoDB shell. This defines the node’s role in a sharded cluster. This optional section allows you to override runtime parameters that fine-tune MongoDB’s behavior. Setting this to false ensures that even localhost connections require authentication. Other parameters can control query timeouts, cursor behavior, or diagnostic logging. Whenever you modify /etc/mongod.conf, you need to restart MongoDB for the changes to take effect: Then verify the service is running: If MongoDB fails to restart, check for syntax errors (YAML indentation mistakes are common) or review the logs: Here’s an example of a clean, production-oriented mongod.conf for Ubuntu 24.04: MongoDB’s flexibility makes it powerful, but it also means that an insecure setup can easily lead to data exposure. In the early days of MongoDB, many servers were left open to the internet without authentication, allowing attackers to list, modify, or even delete databases simply by connecting to port 27017. Today, MongoDB ships with safer defaults, but it’s still up to you to enforce authentication, network restrictions, and encryption. By default, MongoDB starts with authentication disabled. That means anyone who can connect to the database can run administrative commands, drop collections, or modify data without restriction. To prevent this, MongoDB uses a Role-Based Access Control (RBAC) system that you enable explicitly. Open the MongoDB configuration file: Locate the security section, or create one if it doesn’t exist: Save and exit (Ctrl+O, then Ctrl+X). Restart MongoDB so the change takes effect: MongoDB provides a temporary localhost authentication bypass on a fresh deployment so the first administrative user can be created. This bypass is disabled automatically once an admin user exists or if certain security settings (like keyFile or clusterAuthMode) are enabled. That means you can safely create your first admin user before full enforcement begins. The admin user is the foundation of MongoDB’s authentication system. It has permission to create other users, define roles, and grant access to specific databases. To create this account: Start a local MongoDB shell: Switch to the admin database, which stores user credentials and role definitions: Create the user with the following command: Let’s break this down: This command writes a new document to MongoDB’s system.users collection inside the admin database. You can verify this by listing users afterward: Reconnect as the admin user to confirm that authentication is now enforced: Once authenticated, you can run administrative commands such as: If MongoDB prompts for a password and grants access only after authentication, RBAC is functioning correctly. Best practice: Always use long, randomly generated passwords or integrate MongoDB with a secret management system like HashiCorp Vault. In production, your application should never use the admin account. Instead, create dedicated users for each application, each with only the permissions it needs. For example, to create a user for a web application that manages data in a specific database: You can list all users for a database with: Tip: Always separate users by application or environment (for example, appuser_prod and appuser_staging) so credentials can be rotated independently. Even with authentication enabled, it’s dangerous to expose MongoDB to the open internet. Automated scanners routinely look for open ports (particularly 27017, the default MongoDB port), and attempt brute-force attacks or exploit misconfigured instances. By default, MongoDB only listens on 127.0.0.1, the local interface. If your applications and MongoDB server share the same host, you don’t need to change anything. However, if your application connects remotely, you’ll need to explicitly whitelist specific IP addresses. Edit the configuration file: Locate the net section and update it: Replace 192.168.10.50 with your trusted application server’s IP address. This ensures MongoDB accepts connections only from localhost and that specific remote host. Restart the service to apply the changes: Confirm the active bindings: You should see MongoDB listening on both 127.0.0.1:27017 and your specified IP. Note: Avoid using bindIp: 0.0.0.0 on bare-metal or VM deployments unless strict network-level firewall rules are in place. In containerized or orchestrated environments, 0.0.0.0 is commonly required, but must still be protected by firewall or network policies. Even if MongoDB listens only on certain interfaces, it’s best practice to reinforce network security at the operating system level. Ubuntu’s UFW provides an easy way to control inbound and outbound connections. Verify UFW is installed and active: If it shows as inactive, enable it: Allow MongoDB connections only from trusted IPs. For example, if your application server’s IP is 192.168.10.50: Check that the rule was added: You should see an entry allowing port 27017 from the specified source. Optionally, deny all other traffic to MongoDB explicitly: This combination, bindIp in MongoDB’s config and selective UFW rules, ensures that only known systems can reach your database, even if other processes attempt to expose it. Note: For cloud deployments (like DigitalOcean), configure network security groups or VPC firewall rules as an additional layer of protection. So far, you’ve ensured that only trusted users and IPs can access MongoDB. The next step is to secure the data in transit. When a client connects to MongoDB, all data (including authentication credentials and queries) is transmitted as plain text by default. TLS encrypts this data, preventing eavesdropping or tampering. In production, use a certificate from a trusted Certificate Authority (CA). For testing or internal deployments, you can generate a self-signed certificate: Combine them into one PEM file (required by MongoDB): These permissions ensure only the mongodb user can access the key file. Edit /etc/mongod.conf and locate the net section. Add a new tls block beneath it: Restart MongoDB to apply the change: When connecting with mongosh, you must now specify the --tls option: If the connection succeeds and the prompt appears, your TLS configuration is working correctly. You can verify encryption by inspecting the connection using OpenSSL: The output should show the certificate chain and encryption details, for example: This confirms that your MongoDB server is now encrypting traffic end-to-end. Pro Tip: When enabling TLS in a replica set, configure both a keyFile and clusterAuthMode (typically set to x509 or keyFile) so nodes can authenticate each other securely. Once everything is configured, it’s worth double-checking your setup. Check that MongoDB is bound only to allowed IPs: You should see connections limited to 127.0.0.1 and your trusted IPs only. Ensure authentication is enforced. Try connecting without credentials: You should receive an authentication error. Validate that TLS is required. Attempt to connect without --tls: If the connection fails with a message about TLS requirements, your encryption is correctly enforced. Review MongoDB’s internal security parameters: If tlsMode returns "requireTLS", encryption is confirmed active. With authentication, access control, network restrictions, and TLS all configured, your MongoDB instance is now hardened against the most common attack vectors. Once MongoDB is installed and secured, the next major priority is maintaining it effectively. Even the most carefully configured database can become unreliable without regular maintenance. Routine operations such as backups, monitoring, and system updates ensure that MongoDB remains performant, stable, and recoverable over time. A well-planned backup strategy is fundamental to any production database. Backups allow you to recover quickly from hardware failures, software bugs, or accidental deletions. MongoDB supports both logical and physical backups, each suited to different scenarios. A logical backup captures database contents in BSON format using the mongodump utility. This approach is portable, human-readable, and easy to automate. To create a full backup of all databases, run: This command creates a directory named with the current date under /backups/mongodb/ and stores all BSON dumps inside it. If authentication is enabled, use a URI connection string that includes credentials: You can also back up a specific database: To restore from a logical backup, use mongorestore: Or restore a single database: Logical backups are flexible and easy to script, but they can take longer to complete for very large datasets. Recommendation: Schedule daily logical backups using a cron job or systemd timer, and always verify the restore process on a staging server before relying on backups in production. Physical backups capture the database files directly from the storage volume. This method is faster and more space-efficient for large databases, but it requires consistent snapshots to avoid corruption. If you use journaling (which is enabled by default), you can take volume snapshots while MongoDB is running. WiredTiger supports crash-consistent snapshots while MongoDB is running, as long as journaling is enabled. For full application-consistent snapshots, stopping MongoDB is recommended but not required: Take snapshot using your cloud provider or storage system and restart the service: Store snapshots in an offsite or separate region whenever possible. This protects against data center outages or accidental local deletions. Monitoring is critical to prevent issues before they impact users. MongoDB provides built-in command-line tools as well as support for external monitoring systems. The mongostat tool displays live database metrics such as operations per second, memory usage, and active connections. Run it as follows: This produces a real-time table showing inserts, queries, updates, and deletes. Each column represents a key performance indicator, such as the ratio of dirty memory pages or the number of active connections. The mongotop utility focuses on how long MongoDB spends reading and writing per collection. To run it every two seconds, use: This is useful for identifying collections that experience heavy I/O. For persistent visibility and alerting, you can integrate MongoDB with external systems such as: Important metrics to monitor include: Recommendation: Configure alerts for critical thresholds such as high disk utilization, connection spikes, or replication lag exceeding five seconds. MongoDB databases expand dynamically as documents and indexes grow. If disk usage is left unchecked, the database may run out of space, causing it to lock or crash. Check current filesystem usage with: This displays available and used space for MongoDB’s data directory. You can also check memory and cache usage through MongoDB itself: The bytes currently in the cache value indicates how much RAM the WiredTiger storage engine is using. To stay proactive, set up alerts or monitoring checks that notify you when disk usage exceeds 85%. For example, a simple script could be scheduled to run periodically: You can integrate this into systemd timers or monitoring tools for automation. Large or unused collections and log files can consume significant space over time. To manage logs, configure rotation in /etc/logrotate.d/mongodb (as shown later in this section) or clean up manually: For application data, consider using TTL (time-to-live) indexes for collections that store temporary or time-sensitive data: This automatically deletes documents older than seven days. Upgrading MongoDB requires careful planning, especially when moving between major versions. The following process minimizes downtime and ensures compatibility. Confirm the installed version: Always create a full backup before upgrading: If you previously pinned MongoDB packages to prevent automatic updates, remove the holds: Then update your package list and upgrade MongoDB: MongoDB preserves your configuration and data files during upgrades, but a backup guarantees you can roll back if something goes wrong. Verify the service status: Check recent logs for warnings or migration notes: Confirm the new version: Recommendation: For major version upgrades (for example, from 7.x to 8.x), always read the official MongoDB release notes. Some query behaviors or internal storage structures may change. Manual maintenance works for small environments, but automation ensures consistency. You can schedule recurring backups, log rotations, or monitoring checks using cron or systemd timers. Edit the root crontab: Add the following line to back up your MongoDB instance every night at 2 a.m.: This creates a dated backup folder every day. To prevent log files from consuming disk space, create a log rotation configuration file: Add the following content: This configuration keeps five weeks of logs, compresses older files, and reloads MongoDB after rotation. MongoDB’s journaling and replication features rely on accurate timestamps. If the system clock drifts, replication lag or journal corruption may occur after a crash. Ubuntu 24.04 uses systemd-timesyncd by default, but you can also use chrony for more precise time synchronization: You can verify synchronization with: If NTP synchronized shows as yes, your system clock is in sync. MongoDB provides the serverStatus command for comprehensive runtime diagnostics. You can query it directly from the shell: This returns a detailed JSON object containing metrics such as: You can extract specific fields for targeted checks. For example, to view connection statistics: This allows quick insights into whether the system is experiencing connection saturation or resource constraints. Single-node MongoDB deployments work well for development or low-criticality applications. For production environments, you should implement replica sets. Replica sets provide redundancy and automatic failover, ensuring availability even if one node fails. Replica sets also simplify maintenance tasks like backups and scaling. You can offload backups or analytics queries to secondary nodes without impacting primary performance. Your MongoDB instance is now fully operational and properly maintained. MongoDB is designed to scale horizontally, meaning you can increase capacity and performance by adding more servers rather than relying solely on a single, more powerful machine. As your dataset grows or your application begins handling more concurrent queries, scaling ensures that MongoDB continues to perform reliably and efficiently. There are two primary ways to scale MongoDB: A replica set is a group of MongoDB servers that maintain identical copies of your data. Replica sets provide high availability and protect against hardware or network failures. If the primary node fails, one of the secondary nodes automatically takes over, ensuring minimal downtime. A standard replica set consists of: For production systems, MongoDB recommends at least three members in a replica set. To create a replica set, you need at least two or three servers (physical or virtual). Each node should have MongoDB installed and configured. On each node, open the configuration file /etc/mongod.conf and add the replication section: Restart MongoDB on each server: On the primary node, connect to MongoDB and initialize the replica set: The output should show one primary and two secondaries with their state labeled as “PRIMARY” and “SECONDARY.” Replica sets offer several important advantages: Best practice: Use even distribution of replica nodes across different physical zones or availability regions to prevent data loss during outages. Sharding is MongoDB’s strategy for horizontal scaling. When a dataset becomes too large for a single server to store or process efficiently, MongoDB can divide it into smaller chunks distributed across multiple servers called shards. Each shard holds a subset of the data, and the cluster collectively behaves as one logical database. A typical MongoDB sharded cluster includes: The shard key determines how MongoDB distributes data across shards. A poorly chosen shard key can lead to uneven data distribution (known as data skew) or hotspots. Good shard keys typically have: Example of enabling sharding for a database: This command enables sharding on the salesdb database and shards the orders collection using the customer_id field. You should consider sharding when: Sharding adds architectural complexity, so it is best introduced only when necessary. Note: After a collection is sharded, MongoDB does not support unsharding it. Plan your shard key carefully before enabling sharding. MongoDB uses the WiredTiger storage engine by default. It is optimized for modern hardware and uses compression, caching, and multi-threaded I/O. Understanding how WiredTiger manages memory and disk I/O helps improve performance. WiredTiger typically uses approximately 50% of available RAM for its cache, with MongoDB dynamically adjusting this value based on system memory. You can adjust this in the configuration file: This is useful if your system runs other memory-intensive services alongside MongoDB. For dedicated MongoDB servers, leaving the default cache setting is generally best. You can view current cache usage by running: WiredTiger supports data and index compression to reduce disk usage. By default, it uses Snappy compression, which balances performance and space efficiency. You can switch to zlib (for better compression) or zstd (for newer setups) if you prioritize disk savings over speed. Example configuration: Journaling ensures that write operations are durable, even in case of power loss. You can adjust the commitIntervalMs parameter to control how often journal writes occur: Lower intervals improve durability but may reduce write performance slightly. Recommendation: For most production workloads, retain default journaling settings, as WiredTiger’s balance between performance and durability is well tested. It is important to recognize when to scale your MongoDB deployment. Monitoring metrics such as CPU load, memory usage, and I/O wait times will help determine when it is time to add more capacity. When these indicators appear, consider adding more secondaries (for reads) or shards (for write-heavy loads). Vertical scaling involves adding more resources (CPU, RAM, faster disks) to existing servers. It is simpler to manage but limited by hardware capacity. Horizontal scaling involves adding new servers to distribute the workload. This is MongoDB’s strength, as it scales nearly linearly when designed properly. As your system grows, managing a self-hosted cluster can become complex. At this stage, migrating to a managed MongoDB service, like MongoDB Atlas, can significantly reduce operational overhead. Managed platforms handle automatic backups, patching, monitoring, scaling, and encryption. However, they may introduce additional cost and slightly less flexibility compared to self-managed setups. <$>
Recommendation: Stay self-hosted until your team faces consistent operational challenges such as performance bottlenecks, cluster management complexity, or compliance requirements that managed platforms handle more efficiently.
<$> MongoDB can be deployed in two main ways: Each approach has distinct advantages and trade-offs. The right choice depends on your technical expertise, workload characteristics, compliance needs, and operational priorities. Let’s examine these two options in depth. When you self-host MongoDB, you install it directly on your own infrastructure, whether that’s a physical server, a virtual machine, or a cloud instance such as a DigitalOcean Droplet. You control every aspect of the environment, from installation to upgrades and monitoring. In summary, self-hosted MongoDB provides flexibility, independence, and lower cost at small scale but demands significant ongoing maintenance effort. A managed MongoDB service hosts the database on your behalf, handling all infrastructure, updates, scaling, and security patches automatically. These services eliminate most of the administrative overhead while offering high availability and global scalability. In summary, Managed MongoDB services drastically reduce administrative burden and improve reliability but at the cost of flexibility and higher recurring expense. The decision between self-hosted and managed MongoDB depends primarily on your organization’s priorities, resources, and constraints. Consider the following scenarios: Choose Self-Hosted MongoDB if: Choose Managed MongoDB if: Practical recommendation: Many organizations adopt a hybrid approach: they use self-hosted MongoDB for testing, staging, or regional workloads, and managed MongoDB (Atlas) for production systems that demand high uptime and scalability. Even with the most careful configuration and monitoring, issues can arise in a MongoDB deployment. These may include slow performance, failed startups, replication lag, or disk space exhaustion. The key to maintaining a stable MongoDB environment is having a structured approach to diagnosing problems and applying preventive maintenance routines. The first step when troubleshooting MongoDB is to verify whether the database service is running correctly. You can check the current status with the following command: If MongoDB is running, you should see output that includes: If the service is inactive, failed, or dead, restart it: After restarting, check its status again. If it immediately fails, proceed to check the log file for specific errors. Logs are the most direct source of diagnostic information. MongoDB records all major events, warnings, and errors in its main log file located at: To view the most recent entries, run: If MongoDB fails to start, you will typically see one of the following errors: Permission denied: Incorrect ownership or permissions on /var/lib/mongodb or /var/log/mongodb. Check permissions and fix them: Data directory not found: Ensure /var/lib/mongodb exists and matches the path defined in /etc/mongod.conf. Address already in use: Another process is using port 27017. Identify it with: and stop or reconfigure the conflicting service. Corrupted data files: This may occur if MongoDB was shut down abruptly. In such cases, the journal should recover data automatically on restart. If it fails, you may need to restore from backup. Tip: For continuous log inspection during debugging, use: Connection problems are another frequent issue. When clients cannot reach MongoDB, it is usually due to a network, authentication, or configuration problem. The output should show MongoDB bound to 127.0.0.1 (for local connections) and any configured external IPs. If MongoDB is not listening on the expected IP, verify the bindIp field in /etc/mongod.conf: Restart MongoDB after editing: If remote connections fail, confirm that your firewall allows traffic on port 27017: If not, allow connections from specific IPs: From a client system, test whether the port is reachable: If the connection succeeds, the issue is likely related to authentication or user privileges. Authentication issues often occur after enabling access control or changing user credentials. Connect locally and verify: If the output includes "SCRAM-SHA-256", authentication is active. Try connecting using the admin account: If this fails, connect locally without authentication (possible only from localhost when no users exist) and recreate the admin account: Each MongoDB user is defined within a specific database. If you authenticate against the wrong database, authentication will fail. For example, if the user was created in the admin database, you must authenticate against it explicitly: Performance degradation can arise from high memory usage, slow disk I/O, unoptimized queries, or excessive concurrent connections. MongoDB includes several diagnostic tools to identify these issues. Use Linux commands to check system-level metrics: Look for high CPU usage by mongod or disk latency exceeding 10 milliseconds. This displays real-time metrics, including inserts, queries, updates, and deletes per second. If certain operations appear slow, use the MongoDB profiler to identify long-running queries. You can enable the profiler temporarily to log slow queries: This logs any query that takes longer than 100 milliseconds. Recommendation: Keep profiling disabled in production when not troubleshooting to avoid performance overhead. Inefficient queries often stem from missing indexes. To see if MongoDB is using indexes correctly, prepend explain() to your query: If executionStages.stage shows "COLLSCAN", MongoDB is performing a full collection scan. You can create an index to improve performance: Data corruption is rare, but it can occur due to power loss or disk errors. If MongoDB refuses to start and logs show corruption in the WiredTiger files, follow these steps: Backup the current data directory: Attempt a repair operation: If the repair fails, restore data from your most recent backup. Preventive maintenance greatly reduces the chance of unexpected failures. Ensure that your log rotation policy is active. MongoDB supports both internal log rotation (logRotate command) and external rotation via logrotate when logAppend is enabled. You can manually trigger it if logs grow quickly: Collections can become fragmented after many inserts and deletes. compact can reclaim space but is a blocking operation and should rarely be used in production. WiredTiger automatically handles most fragmentation, so compacting is usually unnecessary. Note that this operation locks the database, so perform it during low traffic periods. Run periodic data integrity checks: This verifies that indexes and documents are consistent. Use automated alerts to warn when disk usage exceeds 85% or memory utilization becomes critical. Monitoring tools like Prometheus, Percona PMM, or MongoDB Atlas Monitor can track these metrics over time. When updating MongoDB or the underlying Ubuntu system, always follow a structured process: Backup your data first. Stop the MongoDB service before kernel or library upgrades: Restart the service and confirm it runs correctly: Note: Never interrupt MongoDB during writes or while the journal is active, as this can cause data corruption. Several tools simplify ongoing maintenance and health checks: The final step in maintenance planning is testing recovery procedures. A backup is only useful if it restores correctly. At least once per quarter: By following these troubleshooting and maintenance practices, you can maintain a healthy MongoDB deployment on Ubuntu that remains performant, secure, and resilient over time. Consistent monitoring and maintenance are far less costly than recovering from an outage or data loss event. MongoDB was removed from Ubuntu’s default repositories after version 18.04 because of licensing changes. The MongoDB Server Side Public License (SSPL) is not recognized as open-source by the Debian and Ubuntu projects. As a result, Canonical no longer distributes MongoDB in its official repositories, and users must install it from MongoDB’s own APT repository instead. To uninstall MongoDB and remove all associated files, run the following commands: This stops the MongoDB service, removes all related packages, deletes data and log directories, and cleans up the repository entry. You can check the status of the MongoDB service using: If MongoDB is running, you will see a line stating “Active: active (running)”. Alternatively, you can confirm connectivity by running: If the command returns "ok": 1, MongoDB is active and accepting connections. Yes, MongoDB can run on a small VPS, but with limitations. For basic development or testing workloads, a server with 2 CPU cores, 2 GB of RAM, and 10–20 GB of SSD storage is sufficient. However, for production use, MongoDB performs best on systems with at least 4 CPU cores, 8 GB of RAM, and high-speed SSD or NVMe storage. Low-memory environments may require adjusting the WiredTiger cache size to prevent excessive swapping. MongoDB may fail to start after a repair if the repair process was run as root, which changes ownership of the data files in /var/lib/mongodb to root:root. Since the mongod service runs as the mongodb user, it will not have permission to read or write these files. To fix this, ensure you run the repair command as the mongodb user or restore correct ownership afterward: You can verify MongoDB’s active listeners using: This shows the IP addresses and ports MongoDB is bound to. If you don’t see the expected IP (for example, your application server’s IP), check the bindIp value in /etc/mongod.conf and restart the service. In most cases, no. WiredTiger automatically uses about 50% of system RAM and dynamically adjusts cache usage based on available memory. Only adjust the cacheSizeGB setting if MongoDB shares the server with other memory-intensive applications. Dedicated MongoDB servers should typically keep the default behavior. MongoDB continuously writes operational data to its log file at /var/log/mongodb/mongod.log. Without log rotation, this file can become very large. Ensure you have log rotation configured using logrotate, as described in the maintenance section of the guide, so older logs are compressed or deleted automatically. You should expand your replica set when you notice sustained increases in read traffic, frequent node elections, replication lag, or when you need higher availability across multiple zones or regions. Adding secondaries distributes read load and improves fault tolerance, especially for production environments. After configuring TLS in /etc/mongod.conf, connect using: If the connection succeeds, run: A valid TLS handshake and details such as Protocol: TLSv1.3 confirm that encryption is active. Running MongoDB effectively is not only about installation and setup; it is about maintaining a balance between performance, security, and reliability over time. You now have a fully capable MongoDB system that can support production workloads, scale with demand, and recover from unexpected failures. By applying the principles and best practices outlined in this guide, from daily monitoring to long-term capacity planning, you can operate MongoDB with confidence in any environment. Whether you continue managing it yourself or migrate to a managed service like MongoDB Atlas, your understanding of MongoDB’s inner workings ensures you’ll always remain in control of your data. To learn more about databases, check out the following tutorials: Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases. Learn more about our products This curriculum introduces open-source cloud computing to a general audience along with the skills necessary to deploy applications and websites securely to the cloud. Browse Series: 39 tutorials Former Technical Writer at DigitalOcean. Focused on SysAdmin topics including Debian 11, Ubuntu 22.04, Ubuntu 20.04, Databases, SQL and PostgreSQL. With over 6 years of experience in tech publishing, Mani has edited and published more than 75 books covering a wide range of data science topics. Known for his strong attention to detail and technical knowledge, Mani specializes in creating clear, concise, and easy-to-understand content tailored for developers. This textbox defaults to using Markdown to format your answer. You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link! Thanks for the tutorial, but I’m stuck! When I try to run the cURL command to get the key added, I get the following error: curl: (77) error setting certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead(see apt-key(8)).
gpg: no valid OpenPGP data found. What’s weird is, when I run sudo apt-key list, it shows MongoDB 4.4 key has been added… but when I run sudo apt update, I get an error basically saying there’s no certificate. Hi, thanks for your helpful article. I have used your instructions once and it worked fine. But I’m doing the same thing in my new server, and surprisingly it’s not working! in step 1, I get the following error: The tutorial is okay but after the install I tried to start the mongo service but it failed with the exit-code I used the following commands to fix it and it worked. worked like a charm ! Please complete your information! Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation. Full documentation for every DigitalOcean product. The Wave has everything you need to know about building a business, from raising funding to marketing your product. Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter. New accounts only. By submitting your email you agree to our Privacy Policy Scale up as you grow — whether you're running one virtual machine or ten thousand. Sign up and get $200 in credit for your first 60 days with DigitalOcean.* *This promotional offer applies to new accounts only.