Installation of MongoDB on Red Hat OS
This document explains the installation of MongoDB Replicaset 6.0 on a server with the Red Hat operating system. It is recommended to have Red Hat 8.x or 9.x operating system.
Before Starting the Installation
Very Important
Before starting installations, make sure that the server's hostname is not localhost.localdomain and that each one is unique (by checking with the hostname command). If this is the case, make sure to change it before proceeding with any operations.
#(If necessary) Change the hostname
hostnamectl set-hostname your-new-hostname
Ensure that the hostname is not assigned with an IP-blocked hostname like 127.0.1.1 in the /etc/hosts file.
Make sure that there is no entry in /etc/resolv.conf like "nameserver 127.0.1.1"
Important
In order for the installation to be healthy, Apinizer Kubernetes servers must access the following addresses.
MongoDB:
https://www.mongodb.org/static/pgp/server-6.0.asc
https://repo.mongodb.org/apt/ubuntu
http://nz2.archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1f-1ubuntu2.19_amd64.deb
#1) Operating System Configurations (On All MongoDB Servers)
POWERSHELL
|
#2) Installation of MongoD
#2.1) Operating System Configuration and Installation of MongoDB Application (On All MongoDB Servers)
POWERSHELL
POWERSHELL
POWERSHELL
|
#2.2) MongoDB Configurations (On All MongoDB Servers)
Generating Key:
POWERSHELL
You need to add the following parameters to the /etc/mongod.conf file, adjusting them to your environment:
The expected state of the relevant configuration file:
POWERSHELL
Then, the MongoDB application is started.
POWERSHELL
If MongoDB installation will be done on more than one server, the keys created in the Primary node are transferred to all nodes and the same privileges are given.
POWERSHELL
|
#2.3) ReplicaSet Configuration and Authorization User Definition (MongoDB Primary Server)
Replicaset activation should only be done on the Primary server. Activating Replicaset:
POWERSHELL
Creating an authorized user for Apinizer application:
POWERSHELL
If MongoDB is to be managed by your organization, a user with the following role must be created.
POWERSHELL
|
Changes That May Be Needed
Authorize a user on the previously created MongoDB using the following command lines.
mongosh mongodb://localhost:25080
use admin;
db.grantRolesToUser('admin', [{ role: 'root', db: 'admin' }])
If hostname or IP address needs to be changed:
mongosh mongodb://localhost:25080 --authenticationDatabase "admin" -u "apinizer" -p
cfg = rs.conf()
cfg.members[0].host = "<MONGO_IP_ADDRESS>:25080"
rs.reconfig(cfg)
rs.status()
If a user password needs to be changed:
use admin
db.changeUserPassword("apinizer", passwordPrompt())
#2.4) MongoDB ReplicaSet Installation on Multiple Servers (MongoDB Primary Server)
Apinizer suggests the high availability feature of MongoDB. High availability allows secondary databases to take over when the primary database fails. For high availability in MongoDB, a minimum of three servers is required (1 Primary and 2 Secondary). If the primary server encounters an issue, one of the secondary servers automatically becomes the primary, ensuring uninterrupted operation. Once the primary server is back online, the secondary server remains as a backup. However, this functionality cannot be achieved with fewer than three active servers. To enhance system continuity, servers can be positioned in different locations. High availability is not limited to just three servers; it can also be implemented with an Arbiter or more servers. For more information, you can visit the link: https://www.mongodb.com/docs/manual/core/replica-set-architectures/. When you restart the MongoDB services, you can configure the Secondary nodes on the Primary node using the following commands in a replica set architecture.
BASH
With these steps, a structure consisting of a total of three servers is established, with one being the primary server and the other two being secondary servers. In the event of high availability, if the connection to the primary server is severed or it fails, one of the secondary servers should automatically assume the role of the primary server. To configure this situation, follow the steps outlined for all nodes.
BASH
Priority specifies the likelihood of a node being chosen as the new Primary, and this value can be scaled between 0 and 1. A value of 0 indicates that the node can never become the Primary, while higher values closer to 1 signify a higher priority for becoming the Primary. This setup is prepared assuming that the DNS names such as "mongoDb01, mongoDb02, mongoDb03, k8sWorkerIP" can be resolved by the system. In cases where servers cannot resolve these DNS names, either this issue needs to be corrected or all the DNS names should be fixed as IP addresses. |