During MongoDB installations or usage, you may encounter various issues. You can review examples on this page for commonly encountered situations.

Problem

Installation Error of MongoDb on Centos 7

Reason/Cause

warning: /var/cache/yum/x86_64/7/MongoDB/packages/mongodb-org-mongos-4.2.13-1.el7.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID 058f8b6b: NOKEY
Retrieving key from https://www.mongodb.org/static/pgp/server-4.2.asc

Solution

Doing "gpgcheck=0" on the file below 

sudo vi /etc/yum.repos.d/mongodb.repo


[MongoDB]name=MongoDB Repositorybaseurl=http://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.2/$basearch/
gpgcheck=0
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

Problem

Installation Error of MongoDb on Centos 8

Reason/Cause

If you have any output like the following in “systemctl status mongodb.service -l”:

SELinux is preventing /usr/bin/mongod from read access on the file snmp.

Solution

run these commands and see output of mongodb.service status until errors disappear:

grep mongod /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp
grep ftdc /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp


Problem

Excessive disk usage by the path /var/lib/mongodb

Reason/Cause

Althought this is not a problem on it's own, it may be required to get some more disk space to prevent OS problems'. Especially if journaling is enabled or replicaset uses multi node structure.

Solution

To Resolve;

  • On Multi Node Instances: One of the server's mongod service is shut down, waiting for the primary to pass to another server. All files in the /var/lib/mongodb path are then deleted. When the Mongod service is restarted, only the necessary files will be created with automatic synchronization. It does not cause interruption in operations.


  • On Single Node Instances: It can only be done by making interruptions in operations. The current database is backed up, the running manager is stopped, the database is dropped, the /var/lib/mongodb path is cleared, mongo is restored, the manager is run again.


Problem

Deleting a project and its proxies manually

Reason/Cause

Althought this is not a problem on it's own, it may be required to do so manually.

Solution

To Resolve;

  • Take and convert the current projectId values:
    var validProjectIds = db.project.find({}, {_id: 1}).toArray().map(function(item){ return item._id.toString(); });


  • Find the ones that have not relation to any project:
    var invalidProjectIds = [];
    db.api_proxy.find({}).forEach(function(doc) {
        if( doc.projectId && doc.projectId!=='admin' &&  !validProjectIds.includes(doc.projectId.toString())) {
            if( !invalidProjectIds.includes(doc.projectId.toString())) {             
                invalidProjectIds.push(doc.projectId);
                //print(doc.projectId);
            }
         }
    });


  • Delete the api proxies that are unrelated to and projects:
    invalidProjectIds.forEach(function(invalidProjectId) {
      db.api_proxy.deleteMany({projectId: invalidProjectId});

     });


Problem

Adding the admin user to a project as the project owner

Reason/Cause

Although this is not a problem, it can be applied when quick access to the project is required.

Solution

To Resolve;

#Switching to the Apinizer database
use apinizerdb


#The following command is executed and the content of the incoming ObjectId value is retrieved
db.role.find({name:"Project Owner"}, {_id:1})

#The received value is written to the <OBJECT_ID> field in the command below and the command is executed by typing the desired project name in the <PROJECT_NAME> field.
db.project.updateOne(
  { name:"<PROJECT_NAME>" },
  {
    $push: {
      "projectMember.teamMemberList": {
        userId: "admin",
        roleList: [
          {
            $ref: "role",
            $id: ObjectId("<OBJECT_ID>")
          }
        ]
      }
    }
  }
)

Problem

If the hostname of the node in the MongoDB Replicaset is going to change

Reason/Cause

When the hostname of a node currently running in a MongoDB cluster is changed, some configurations and credentials may conflict with the old hostname. Therefore, when performing this operation, the node whose hostname is to be changed must be removed from the replica set, the hostname information must be changed, and then the node must be added back to the replica set.

Solution

Things to Consider Before Starting Work

  • These operations must be performed with attention to fault tolerance in the MongoDB replicaset, otherwise interruptions may occur (MongoDB (n-1)/2 tolerance).
  • It is recommended that a full system backup be taken before performing this type of operation.

1. Mongo Backup is taken before work:

Connect to the primary node and take a backup of Apinizer's mongodb database.

mongosh mongodb://localhost:25080 --authenticationDatabase "admin" -u "apinizer" -p 
show dbs
use apinizerdb
# Large collections in the database are checked.
db.getCollectionNames().map(name => ({storageSizeMB: (db.getCollection(name).stats().storageSize / (1024*1024)).toFixed(2), name: name})).sort((a,b) => a.storageSizeMB - b.storageSizeMB).forEach(printjson);

# If there is a large collection and you do not want to back it up, you can use the --excludeCollection <Collection_Name> parameter.
sudo mongodump --host localhost --port=25080 --username=apinizer --password=passwd -d apinizerdb --authenticationDatabase=admin --gzip --archive=/home/apinizer/mongodump/apinizer-backup-v<Apinizer Version>-<Date>--1.archive
BASH

2. The node whose hostname will change is removed from the MongoDB replicaset.

mongosh mongodb://localhost:25080 --authenticationDatabase "admin" -u "apinizer" -p 
rs.status()

# If the server is the primary node, it is first converted to secondary and connected to the new primary (rs.stepDown())
rs.remove("<NODES_OLD_HOSTNAME>")
rs.status()

# Connect to the server whose hostname will be changed and stop the mongodb service.
sudo systemctl stop mongod
sudo hostnamectl set-hostname <NODES_NEW_HOSTNAME>
sudo reboot

hostname
# If the old hostname is still listed for the IP address 127.0.0.1 in /etc/hosts, this section must be replaced with the new hostname.
sudo vi /etc/hosts
sudo systemctl start mongod

# Connect to the primary server and add the node replica with the changed hostname.
rs.add("<NODES_NEW_HOSTNAME>")

# Waiting for data synchronization to complete.
rs.status()
BASH