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>")
          }
        ]
      }
    }
  }
)