Skip to content

Percona Operator for MongoDB 1.14.0

Release Highlights

  • Backups and Restores are critical for business continuity. With this release you can significantly reduce your Recovery Time Objective (RTO) with Physical backups support in the Operator. The feature is now in technical preview.
  • MongoDB 6.0 comes with a variety of improvements and new features. It is now fully supported by the Operator. See our documentation to learn how to upgrade.

New Features

  • K8SPSMDB-713 Physical backups are now supported by the Operator to recover big data sets faster

  • K8SPSMDB-737 MongoDB 6.0 is now officially supported in addition to 4.x and 5.x versions. Read more about version 6 in our blog post

  • K8SPSMDB-824 New ignoreAnnotations and ignoreLabels Custom Resource options allow to list specific annotations and labels for Kubernetes Service objects, which the Operator should ignore (useful with various Kubernetes flavors which add annotations to the objects managed by the Operator)

Improvements

  • K8SPSMDB-658 The Operator log messages appearing during the pause/unpause of the cluster were improved to more clearly indicate this event

  • K8SPSMDB-708 The new initContainerSecurityContext option allows to configure securityContext for the container which can be used instead of the official image during the initial Operator installation

  • K8SPSMDB-721 The backup subsystem was improved so that database is not crashing in case if the backup agent is not able to connect to MongoDB (e.g. due to misconfigured password)

  • K8SPSMDB-758 The ServiceMesh fully qualified domain names (FQDNs) for config servers are now prioritized if DNSMode is set to ServiceMesh (thanks to Jo Lyshoel for contribution)

  • K8SPSMDB-793 It is now possible to set annotations and labels for Persistent Volume Claims for better integration with Cloud Native tools

  • K8SPSMDB-803 The Operator now does not attempt to start Percona Monitoring and Management (PMM) client sidecar if the corresponding secret does not contain the pmmserver or pmmserverkey key

  • K8SPSMDB-817 Adding external nodes to the cluster is now allowed even when the replica set is not exposed. This unblocks the creation of complex multi-cluster topologies

  • K8SPSMDB-844 Update the RuntimeClass API version to v1 from the v1beta1, which was already deprecated since the Kubernetes version 1.22

  • K8SPSMDB-848 Remove formatted strings from log messages to avoid confronting with structured logging based on key-value pairs

  • K8SPSMDB-882 Percona Server for MongoDB Helm chart now persists data by default instead of deleting Persistent Volumes after the cluster deletion

  • CLOUD-768 Helm charts now use random passwords generated by the Operator by default instead of providing pre-configured passwords specified in the values file

  • K8SPSMDB-853 To improve the operator we capture anonymous telemetry and usage data. In this release we add more data points to it

  • K8SPSMDB-867 The Operator now configures replset members using local fully-qualified domain names (FQDN) resolvable and available only from inside the cluster instead of using IP addresses; the old behavior can be restored by setting the clusterServiceDNSMode option to External

Bugs Fixed

  • K8SPSMDB-784 Fix a bug due to which the enableEncryption MongoDB configuration option was always activated when using psmdb-db Helm Chart

  • K8SPSMDB-796 Fix a bug due to which backup failed if replica set was exposed

  • K8SPSMDB-854 Fix a bug due to which backup got stuck after the cluster was exposed

  • K8SPSMDB-471 Fix a bug due to which in case of scheduled backups with error status delete-backup finalizer didn’t allow to delete the appropriate failed resources and the Kubernetes namespace (thanks to Aliaksandr Karavai for reporting)

  • K8SPSMDB-674 Fix a bug that caused the Operator not deleting unneeded Services after the replica set exposing is turned off

  • K8SPSMDB-742 Fix a bug that caused the updates of the sharding.mongos.expose.serviceAnnotations option to be silently rejected

  • K8SPSMDB-766 and K8SPSMDB-767 Fix a bug where the combination of delete-psmdb-pods-in-order and delete-psmdb-pvc finalizers was not working

  • K8SPSMDB-770 We now mention the namespace name in the log message to ease debugging when the cluster-wide mode is used

  • K8SPSMDB-797 Fix the backup/restore documentation not clearly mentioning that user should specify the bucket for the S3 storage

  • K8SPSMDB-820 Fix a bug which prevented the parallel backup jobs execution for different MongoDB clusters in the cluster-wide mode

  • K8SPSMDB-823 Fix a bug where backups were not working in case of ReplicaSet exposed with NodePort

  • K8SPSMDB-836 Fix backups being incorrectly marked as error while still being in starting status

  • K8SPSMDB-841 Fix a bug which turned the cluster into unready status after switching from the LoadBalancer expose to ClusterIP

  • K8SPSMDB-843 Fix a bug which made the cluster unable to start if it was recreated with the same Custom Resource after delete without deleting PVCs and Secrets

  • K8SPSMDB-846 Fix a bug due to which scaling the replica set down to 1 instance caused the last Pod to remain Secondary instead of becoming Primary

  • K8SPSMDB-866 Fix the bug due to which the Operator was continuously flooding the log with error messages if the PMM server credentials were missing

Known Issues and Limitations

  • K8SPSMDB-875 Physical backups cannot be restored on the clusters with arbiter, non-voting, or delayed members due to current Percona Backup for MongoDB limitations

  • K8SPSMDB-846 After switching the cluster to unsafe mode by setting allowUnsafeConfig: true, it is not possible to switch back into safe mode. The user can still scale the cluster safely, but the flag is ignored

Supported Platforms

The Operator was developed and tested with Percona Server for MongoDB 4.4.18, 5.0.14, and 6.0.4. Other options may also work but have not been tested.

The following platforms were tested and are officially supported by the Operator 1.14.0:

This list only includes the platforms that the Percona Operators are specifically tested on as part of the release process. Other Kubernetes flavors and versions depend on the backward compatibility offered by Kubernetes itself.

Get expert help

If you need assistance, visit the community forum for comprehensive and free database knowledge, or contact our Percona Database Experts for professional support and services. Join K8S Squad to benefit from early access to features and “ask me anything” sessions with the Experts.

Community Forum Get a Percona Expert Join K8S Squad

Last update: 2024-04-22