Managed MongoDB Service

MongoDB is a popular document-oriented NoSQL database known for its flexibility and scalability. The Managed MongoDB Service provides a self-healing replicated cluster managed by the Percona Operator for MongoDB.

Deployment Details

This managed service is controlled by the Percona Operator for MongoDB, ensuring efficient management and seamless operation.

• Docs: https://docs.percona.com/percona-operator-for-mongodb/
• Github: https://github.com/percona/percona-server-mongodb-operator

Deployment Modes

Replica Set Mode (default)

By default, MongoDB deploys as a replica set with the specified number of replicas. This mode is suitable for most use cases requiring high availability.

Sharded Cluster Mode

Enable sharding: true for horizontal scaling across multiple shards. Each shard is a replica set, and mongos routers handle query routing.

Notes

External Access

When external: true is enabled:

• Replica Set mode: Traffic is load-balanced across all replica set members. This works well for read operations, but write operations require connecting to the primary. MongoDB drivers handle primary discovery automatically using the replica set connection string.
• Sharded mode: Traffic is routed through mongos routers, which handle both reads and writes correctly.

Credentials

The chart generates the operator’s system-user passwords and writes them to <release>-percona-server-mongodb-users before the operator starts, so <release>-credentials carries a working password and uri from the first install onwards. An upgrade reuses what the secret already holds and never rotates a live password.

A database created before this behaviour landed keeps the secret the operator generated for it, and its <release>-credentials is filled on the next upgrade of the release with the password the operator had already assigned.

Data lifecycle

When the MongoDB release is uninstalled, the operator finalizers reclaim release-scoped resources:

Reclaimed by the percona.com/delete-psmdb-pvc finalizer:

• All PVCs backing the replica set storage. Whether the underlying PersistentVolume and on-disk data are actually deleted depends on the StorageClass reclaimPolicy (Delete removes them, Retain leaves them for manual cleanup).
• Operator-managed secrets:
  • <release>-percona-server-mongodb-users — operator users credentials
  • internal-<release> — internal operator state
  • internal-<release>-users — operator-internal users data
  • <release>-mongodb-encryption-key — at-rest encryption key

Reclaimed by helm uninstall:

• <release>-credentials — connection string for application code
• <release>-user-<username> — per-user passwords
• <release>-s3-creds — backup destination credentials (if backups are configured)

Not reclaimed automatically:

• TLS secrets <release>-ssl and <release>-ssl-internal (issued by cert-manager) remain in the namespace after uninstall. Delete them manually if no longer needed.

Recovery from a stuck deletion:

If the psmdb-operator is uninstalled before MongoDB CRs are deleted, the finalizers cannot run and the PerconaServerMongoDB CR hangs in Terminating. To recover, clear the finalizers manually:

kubectl --namespace <namespace> patch psmdb <release> --type merge --patch '{"metadata":{"finalizers":[]}}'

Note that this skips the operator-driven cleanup — PVCs and operator-managed secrets will remain orphaned and must be removed manually.

If you need to retain data, take a backup before deletion. Refer to the Percona Operator for MongoDB documentation for backup/restore workflows.

Upgrading from earlier versions

Earlier versions of this chart referenced a namespace-shared system users secret (percona-server-mongodb-users). A release that scopes this secret per CR (<release>-percona-server-mongodb-users) renders the new secret on the next upgrade without rotating anything: while the per-release secret does not exist yet, the chart reads the current system-user passwords back from the operator’s own copy, internal-<release>-users, and writes those same values into the new users secret and into <release>-credentials. The Percona operator sees unchanged values and leaves the running users alone; pods are not restarted and the cluster stays available.

Carried over on upgrade:

• The five operator-managed system accounts: databaseAdmin, userAdmin, backup, clusterAdmin, clusterMonitor keep their passwords.
• Secret <release>-percona-server-mongodb-users is created per CR with the values already held by internal-<release>-users.
• Secret <release>-credentials is filled with the existing databaseAdmin password and the matching uri. Installs where these keys were empty get them on the next upgrade, because Helm re-renders only when the spec changes.

Not affected:

• Custom users defined under users: in chart values. Their <release>-user-<name> secrets are not touched.
• The at-rest encryption key (<release>-mongodb-encryption-key) and replica set keyfile (<release>-mongodb-keyfile) are unchanged, so on-disk data remains readable.

Action required after upgrade:

Workloads that mounted <release>-credentials while its password and uri were empty see the filled values only after they re-read the secret. Restart those pods, or run a controller such as Reloader to roll them automatically.

Orphaned legacy secret:

The previous namespace-shared secret percona-server-mongodb-users is no longer referenced by any MongoDB CR after upgrade, but the operator does not garbage-collect it. If multiple MongoDB releases in the same namespace previously shared it, all of them rotate to their own per-CR secrets — passwords are no longer shared across CRs in the namespace, which is the intended outcome. Confirm no other consumers reference it, then remove it manually:

kubectl --namespace <namespace> delete secret percona-server-mongodb-users

storageClass is annotated as immutable in the chart schema — see docs/storage-immutability.md for the contract and which consumers enforce it.

Parameters

Common parameters

Sharding configuration

Users configuration

Databases configuration

Backup parameters

Bootstrap (recovery) parameters