Install MongoDB Community on Red Hat or CentOS using .tgz Tarball
On this page
Note
MongoDB Atlas
MongoDB Atlas is a hosted MongoDB service option in the cloud which requires no installation overhead and offers a free tier to get started.
Overview
Use this tutorial to manually install MongoDB 5.0 Community
Edition on Red Hat Enterprise Linux, CentOS Linux, or Oracle Linux
[1] using a downloaded .tgz
tarball.
MongoDB Version
This tutorial installs MongoDB 5.0 Community Edition. To install a different version of MongoDB Community, use the version drop-down menu in the upper-left corner of this page to select the documentation for that version.
Installation Method
While MongoDB can be installed manually via a downloaded .tgz
tarball as described in this document, it is recommended to use the
yum
package manager on your system to install MongoDB if
possible. Using a package manager automatically installs all needed
dependencies, provides an example mongod.conf
file to get you
started, and simplifies future upgrade and maintenance tasks.
➤ See Install MongoDB using the yum Package Manager for instructions.
Considerations
MongoDB Shell, mongosh
When you use the .tgz
package to install the server, you need to
follow the mongosh installation instructions to
download and install mongosh separately.
Platform Support
Note
EOL Notice
MongoDB 5.0 Community Edition supports the following 64-bit versions of Red Hat Enterprise Linux (RHEL), CentOS Linux, Oracle Linux [1], Rocky Linux, and AlmaLinux [2] on x86_64 architecture:
RHEL / CentOS / Oracle / Rocky / AlmaLinux 8
RHEL / CentOS / Oracle 7
MongoDB 5.0 Community Edition also supports the ARM64 architecture on RHEL / CentOS / Oracle / Rocky / AlmaLinux 8.
See Platform Support for more information.
[1] | (1, 2) MongoDB only supports Oracle Linux running the Red Hat Compatible Kernel (RHCK). MongoDB does not support the Unbreakable Enterprise Kernel (UEK). |
[2] | MongoDB on-premises products released for RHEL version 8.0+ are compatible with and supported on Rocky Linux version 8.0+ and AlmaLinux version 8.0+, contingent upon those distributions meeting their obligation to deliver full RHEL compatibility. |
Production Notes
Before deploying MongoDB in a production environment, consider the Production Notes for Self-Managed Deployments document which offers performance considerations and configuration recommendations for production MongoDB deployments.
Install MongoDB Community Edition
Prerequisites
Use the following command to install the dependencies required for the
MongoDB Community .tgz
tarball:
sudo yum install libcurl openssl xz-libs
Procedure
Follow these steps to manually install MongoDB Community Edition from
the .tgz
.
Download the tarball.
After you have installed the required prerequisite packages, download
the MongoDB Community tgz
tarball from the following link:
In the Version dropdown, select the version of MongoDB to download.
In the Platform dropdown, select your operating system version and architecture.
In the Package dropdown, select tgz.
Click Download.
Ensure the binaries are in a directory listed in your PATH
environment variable.
The MongoDB binaries are in the bin/
directory of the tarball.
You can either:
Copy the binaries into a directory listed in your
PATH
variable, such as/usr/local/bin
(Update/path/to/the/mongodb-directory/
with your installation directory as appropriate)sudo cp /path/to/the/mongodb-directory/bin/* /usr/local/bin/ Create symbolic links to the binaries from a directory listed in your
PATH
variable, such as/usr/local/bin
(Update/path/to/the/mongodb-directory/
with your installation directory as appropriate):sudo ln -s /path/to/the/mongodb-directory/bin/* /usr/local/bin/
Install the MongoDB Shell (mongosh
).
Install mongosh
then use the MongoDB Shell
to connect to your deployment.
Run MongoDB Community Edition
Prerequisites
ulimit
Most Unix-like operating systems limit the system resources that a
process may use. These limits may negatively impact MongoDB operation,
and should be adjusted. See UNIX ulimit
Settings for Self-Managed Deployments for the recommended
settings for your platform.
Note
If the ulimit
value for number of open files is under 64000
, MongoDB
generates a startup warning.
Directory Paths
To Use Default Directories
By default, MongoDB runs using the mongod
user account and
uses the following default directories:
/var/lib/mongo
(the data directory)/var/log/mongodb
(the log directory)
Create the MongoDB data and log directories:
sudo mkdir -p /var/lib/mongo sudo mkdir -p /var/log/mongodb
By default, MongoDB runs using the mongod
user account. Create
a mongod
and a mongodb
group. Ensure that the mongod
belongs to the group then set the owner and group of these directories
to mongod
:
sudo chown -R mongod:mongod /var/lib/mongo sudo chown -R mongod:mongod /var/log/mongodb
To Use Non-Default Directories
To use a data directory and/or log directory other than the default directories:
Create the new directory or directories.
Edit the configuration file
/etc/mongod.conf
and modify the following fields accordingly:storage.dbPath
to specify a new data directory path (e.g./some/data/directory
)systemLog.path
to specify a new log file path (e.g./some/log/directory/mongod.log
)
Ensure that the user running MongoDB has access to the directory or directories:
sudo chown -R mongod:mongod <directory> If you change the user that runs the MongoDB process, you must give the new user access to these directories.
Configure SELinux if enforced. See Configure SELinux.
Configure SELinux
Important
If SELinux is in enforcing
mode, you must customize your SELinux
policy for MongoDB by making the following two policy adjustments:
Permit Access to cgroup
The current SELinux Policy does not allow the MongoDB process to
access /sys/fs/cgroup
, which is required to determine
the available memory on your system. If you intend to run SELinux in
enforcing
mode, you will need to make the following adjustment
to your SELinux policy:
Ensure your system has the
checkpolicy
package installed:sudo yum install checkpolicy Create a custom policy file
mongodb_cgroup_memory.te
:cat > mongodb_cgroup_memory.te <<EOF module mongodb_cgroup_memory 1.0; require { type cgroup_t; type mongod_t; class dir search; class file { getattr open read }; } #============= mongod_t ============== allow mongod_t cgroup_t:dir search; allow mongod_t cgroup_t:file { getattr open read }; EOF Once created, compile and load the custom policy module by running these three commands:
checkmodule -M -m -o mongodb_cgroup_memory.mod mongodb_cgroup_memory.te semodule_package -o mongodb_cgroup_memory.pp -m mongodb_cgroup_memory.mod sudo semodule -i mongodb_cgroup_memory.pp
The MongoDB process is now able to access the correct files with
SELinux set to enforcing
.
Permit Access to netstat
for FTDC
The current SELinux Policy does not allow the MongoDB process to open
and read /proc/net/netstat
, which is required for
Full Time Diagnostic Data Capture (FTDC).
If you intend to run SELinux in
enforcing
mode, you will need to make the following adjustment
to your SELinux policy:
Ensure your system has the
checkpolicy
package installed:sudo yum install checkpolicy Create a custom policy file
mongodb_proc_net.te
:cat > mongodb_proc_net.te <<EOF module mongodb_proc_net 1.0; require { type cgroup_t; type configfs_t; type file_type; type mongod_t; type proc_net_t; type sysctl_fs_t; type var_lib_nfs_t; class dir { search getattr }; class file { getattr open read }; } #============= mongod_t ============== allow mongod_t cgroup_t:dir { search getattr } ; allow mongod_t cgroup_t:file { getattr open read }; allow mongod_t configfs_t:dir getattr; allow mongod_t file_type:dir { getattr search }; allow mongod_t file_type:file getattr; allow mongod_t proc_net_t:file { open read }; allow mongod_t sysctl_fs_t:dir search; allow mongod_t var_lib_nfs_t:dir search; EOF Once created, compile and load the custom policy module by running these three commands:
checkmodule -M -m -o mongodb_proc_net.mod mongodb_proc_net.te semodule_package -o mongodb_proc_net.pp -m mongodb_proc_net.mod sudo semodule -i mongodb_proc_net.pp
Important
In addition to the above, you will also need to further customize
your SELinux policy in the following two cases if SELinux is in
enforcing
mode:
You are using a custom directory path instead of using the default
dbPath
,systemLog.path
, orpidFilePath
in RHEL 7.0 or later, and/orYou are using a custom port instead of using the default MongoDB ports.
Using a Custom MongoDB Directory Path
Update the SELinux policy to allow the
mongod
service to use the new directory:sudo semanage fcontext -a -t <type> </some/MongoDB/directory.*> where specify one of the following types as appropriate:
mongod_var_lib_t
for data directorymongod_log_t
for log file directorymongod_var_run_t
for pid file directory
Note
Be sure to include the
.*
at the end of the directory.Update the SELinux user policy for the new directory:
sudo chcon -Rv -u system_u -t <type> </some/MongoDB/directory> where specify one of the following types as appropriate:
mongod_var_lib_t
for data directorymongod_log_t
for log directorymongod_var_run_t
for pid file directory
Apply the updated SELinux policies to the directory:
sudo restorecon -R -v </some/MongoDB/directory>
For example:
Tip
Be sure to include the .*
at the end of the directory for the
semanage fcontext
operations.
If using a non-default MongoDB data path of
/mongodb/data
:sudo semanage fcontext -a -t mongod_var_lib_t '/mongodb/data.*' sudo chcon -Rv -u system_u -t mongod_var_lib_t '/mongodb/data' sudo restorecon -R -v '/mongodb/data' If using a non-default MongoDB log directory of
/mongodb/log
(e.g. if the log file path is/mongodb/log/mongod.log
):sudo semanage fcontext -a -t mongod_log_t '/mongodb/log.*' sudo chcon -Rv -u system_u -t mongod_log_t '/mongodb/log' sudo restorecon -R -v '/mongodb/log'
Using a Custom MongoDB Port
sudo semanage port -a -t mongod_port_t -p tcp <portnumber>
Note
You might need to restart mongod
for the custom port
to be recognized.
Procedure
Follow these steps to run MongoDB Community Edition on your system. These instructions assume that you are using the default settings.
Create the data and log directories.
Create a directory where the MongoDB instance stores its data. For example:
sudo mkdir -p /var/lib/mongo
Create a directory where the MongoDB instance stores its log. For example:
sudo mkdir -p /var/log/mongodb
The user that starts the MongoDB process must have read and write permission to these directories. For example, if you intend to run MongoDB as yourself:
sudo chown `whoami` /var/lib/mongo # Or substitute another user sudo chown `whoami` /var/log/mongodb # Or substitute another user
Verify that MongoDB has started successfully.
Verify that MongoDB has started successfully by
checking the process output for the following line in the
log file /var/log/mongodb/mongod.log
:
[initandlisten] waiting for connections on port 27017
You may see non-critical warnings in the process output. As long as you see the log line shown above, you can safely ignore these warnings during your initial evaluation of MongoDB.
Begin using MongoDB.
Start a mongosh
session on the same host machine as the
mongod
. You can run mongosh
without any command-line options to connect to a
mongod
that is running on your localhost with default
port 27017.
mongosh
For more information on connecting using mongosh
,
such as to connect to a mongod
instance running
on a different host and/or port, see the
mongosh documentation.
To help you start using MongoDB, MongoDB provides Getting Started Guides in various driver editions. For the driver documentation, see Start Developing with MongoDB.
Additional Information
Localhost Binding by Default
By default, MongoDB launches with bindIp
set to
127.0.0.1
, which binds to the localhost network interface. This
means that the mongod
can only accept connections from
clients that are running on the same machine. Remote clients will not be
able to connect to the mongod
, and the mongod
will
not be able to initialize a replica set unless this value is set
to a valid network interface which is accessible from the remote clients.
This value can be configured either:
Warning
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist for Self-Managed Deployments. At minimum, consider enabling authentication and hardening network infrastructure.
For more information on configuring bindIp
, see
IP Binding in Self-Managed Deployments.