Known issues and limitations for MongoDB

The following known issues and limitations apply to the MongoDB service.

Limitations

MongoDB database pods remain in 0/1 status or continuous restart after applying the patch command
Applies to: 5.1.0 and later

Once the database instance is upgraded to version 5.1.x or later, the db pods might remain in 0/1 or 1/1 with continuous restarting status after applying the patch command. This issue occurs due to a limitation with the enterprise MongoDB operator.

As a workaround, restart the mongodb-enterprise-operator to bring all the pods back to 1/1 status.
oc delete po mongodb-enterprise-operator-xxxxx -n namespace
Also, delete the database pod that remains in 0/1 status.
oc delete po dbpodname-mongodb-x
The database pods are back to 1/1 status with the upgraded version.
An error occurs during ODAP backup
Applies to: 5.1.1
Fixed in: 5.1.2

During OADP backup, the following error message is displayed:

level=error msg=global registry check failed: 1 error occurred:
* error from addOnId=opsmanager: addOnId=opsmanager (state=enabled) is in zen-metastore,
        but does not exist in the global registry

As a workaround, run one of the following commands:

cpd-cli oadp tenant-backup create ... --registry-check-exclude-add-on-ids
      opsmanager

or

cpd-cli oadp tenant-backup create ... ---skip-registry-check
MongoDB pods do not got down when the service is shut down
Applies to: 5.1.1
Fixed in: 5.1.2
cpd-cli manage shutdown  --components=mongodb_cp4d  --cpd_instance_ns=project_name
As a workaround, complete the following steps:
  1. Shut down the service.
    oc patch CPDMongoDB db_name --namespace project_name --type=merge --patch '{"spec": {"shutdown": true}}'
  2. Restart the service.
    oc patch CPDMongoDB db_name --namespace project_name --type=merge --patch '{"spec": {"shutdown": false}}'
The MongoDB instance remains in Pending state when a ResourceQuota is applied to the cluster
Applies to: 5.1.0 and later
Fixed in: 5.1.2

After you upgrade the MongoDB service to Version 5.1.0, the MongoDB instance fails to run or remains in Pending state when a ResourceQuota is applied to the cluster.

As a workaround, apply limit range with defaults for limits and requests. For example, you can apply the limit range to the zen namespace as shown in the following yaml:
apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-limits
  namespace:  zen  
spec:
  limits:
  - default:
      cpu: 300m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 200Mi
    type: Container
After completing the MongoDB upgrade to Version 5.1, the service instance still displays the pre-upgrade version
Applies to: 5.1.0
Fixed in: 5.1.1

After you complete the MongoDB upgrade to Version 5.1, the cpd-cli service-instance list command output still displays the Upgrade version option as 5.1.0. This is because the Version 5.1.0 supports the same version of databases as the pre-upgrade version (for example, Version 4.8.7).

Downloading the logs from the Log Request History page fails repeatedly
Applies to: 5.1.0 and later
When you attempt to download the logs from the Log Request History page, the download fails and the following error message is displayed.
We are having trouble finding the site
As a workaround, complete the following steps:
  1. Go to the Log Request History page.
  2. Copy the Log Request History page URL from the beginning http://mongodb until /log.
    For example, the copied URL must be similar to the following URL:
    http://mongodb-opsmanagerinstance-ops-manager-svc-cpd-instance.cp4d-vpc-box-98b7318c91b01bd72490e80cc2328915-0000.us-south.containers.appdomain.cloud/log
  3. Replace the download URL from the beginning http://mongodb until /log with the copied URL.
    For example, after you replace or edit the download URL, the final URL must be similar to the following URL:
    http://mongodb-opsmanagerinstance-ops-manager-svc-cpd-instance.cp4d-vpc-box-98b7318c91b01bd72490e80cc2328915-0000.us-south.containers.appdomain.cloud/log/collection/request/6622da994eaf806f9e9bb4c1/6622df20d6130751da3634b2/download

    Result: The logs are downloaded automatically.

The MongoDB Ops Manager user interface fails to load or work with data.
Applies to: 5.1.0 and later

After creating a new MongoDB database instance, the MongoDB Ops Manager user interface is not able to load, edit or work with any data.

Workaround: Add MongoDB users that need access to the database by inviting them to the project manually.
  1. Access the MongoDB Ops Manager user interface.
  2. Navigate to the project where the failing MongoDB instance is stored.
  3. From the Project Access Manager page, click Invite to Project.
  4. Enter the user name of the user that you want to grant access to the project and assign them Project Owner privileges.