v0.10.0

Release highlights

PMM3 support

The Operator is natively integrated with PMM 3, enabling you to monitor the health and performance of your Percona Server MySQL deployment and at the same time enjoy enhanced performance, new features, and improved security that PMM 3 provides.

Note that the support for PMM2 is dropped. This means you must do the following to monitor your deployment further:

• transition to PMM 3 if you had PMM 2 to. The PMM documentation explains how to upgrade.
• run the Operator version 0.10.0. Check the Upgrade the Operator tutorial for the update steps.
• ensure that PMM 3 Server version must be equal to or newer than the PMM Client.

Support for deployments on OpenShift

OpenShift is a fully integrated Kubernetes-based platform enhanced with automation, security, and developer-friendly tools. You can now deploy Percona Operator for MySQL based on Percona Server for MySQL on OpenShift and benefit from its portability across hybrid clouds. The Operator also fully supports the Red Hat OpenShift lifecycle which ensures its security and reliability.

Follow our installation guide to install the Operator on OpenShift.

Added labels to identify the version of the Operator

CRD is compatible with the last 3 Operator versions. To know which Operator version is attached to it, we've added lables to all Custom Resource Definitions. The labels help you identify the current Operator version and decide if you need to update the CRD.

To view the labels, run: kubectl get crd perconaservermysqls.ps.percona.com --show-labels

Improved configuration validation during cluster deployment

The Operator now enforces these mandatory parameters to have values when it deploys the database cluster:

• .spec.mysql.size
• .spec.proxy.haproxy.size
• .spec.proxy.router.size
• .spec.orchestrator.size
• .spec.backup.pitr.binlogServer.size

If any of the following configuration options are empty, the deployment fails.

This improved validation ensures that every cluster is deployed with the necessary settings for stability and functionality.

Changelog

New features

• K8SPS-393 - Added support for PMM v3

• K8SPS-110 - Added support for OpenShift

Improvements

• K8SPS-135 - Use MD5 hashing for stored configuration

• K8SPS-320 - Added labels to TLS and user secret objects created by the Operator

• K8SPS-357, K8SPS-423 - Added the state-monitor utility to read MySQL state during startup. It is a valuable tool to improve cluster provisioning

• K8SPS-382 - Removed the loadBalancerIP Service type as deprecated

• K8SPS-392 - Added the ability to increase timeout for the CLONE operation while bootstrapping a cluster (Thank you Alexander Kuleshov for reporting this issue)

• K8SPS-426 - Added Labels for Custom Resource Definitions (CRD) to identify the Operator version attached to them

Bugs Fixed

• K8SPS-212 - Improved the Custom Resource validation during a cluster deployment when the .mysql.clusterType is set to async. The validation rules verify that HAProxy and Orchestrator are enabled, while MySQL Router is disabled for async deployments. The corresponding log message is also printed. This helps ensure your cluster is configured according to the requirements for this replication type.

• K8SPS-221 - Fixed a bug with bootstrapping the cluster after crash when the clusterType is set to group-replication. The fix uses the state-monitor utility that checks MySQL state and proceeds with bootstrappins based on the database state.

• K8SPS-299 - Fixed the issue with the Operator failing to initialize the cluster when the size for MySQL is absent in Custom Resource manifest by making the parameters that affect cluster operation mandatory for deployment. If any option has no value, the Operator fails to deploy the cluster

• K8SPS-365 - Fixed the issue with clusterType set to group-replication failing after the upgrade of the MySQL image. The issue was fixed by removing the excessive restart of the mysql container after adding a pod to the cluster.

• K8SPS-375 - Improved the cluster startup process by handling reconciling errors

• K8SPS-379 - Automated the ClusterRole generation when installing the Operator in a cluster-wide mode

• K8SPS-387 - Added the wait_for_delete function to ensure that the cluster or its components are fully cleaned up before performing operations like restoration, scaling, or re-deployment.

Deprecation and removal

The loadBalancerIP type for the Service objects is deprecated in Kubernetes v1.24+. It is removed from the HAProxy and Router subsections of the deploy/cr.yaml Custom Resource manifest. Please refer to Kubernetes documentation for recommendations how to proceed if you have defined this type before.

Supported software

The Operator was developed and tested with the following software:

• Percona Server for MySQL 8.0.42-33
• Orchestrator 3.2.6-17
• MySQL Router 8.0.42
• XtraBackup 8.0.35-33
• Percona Toolkit 3.7.0
• HAProxy 2.8.14
• PMM Client 3.2.0

Other options may also work but have not been tested.

Supported platforms

Percona Operators are designed for compatibility with all CNCF-certified Kubernetes distributions. Our release process includes targeted testing and validation on major cloud provider platforms and OpenShift, as detailed below for Operator version 0.9.0:

• Google Kubernetes Engine (GKE) 1.30 - 1.32
• Amazon Elastic Container Service for Kubernetes (EKS) 1.30 - 1.32
• OpenShift 4.15 - 4.18
• Minikube 1.36.0 (based on Kubernetes 1.33.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 backward compatibility offered by Kubernetes itself.

v0.9.0

Installation

Installing Percona Operator for MySQL

Percona Operator for MySQL allows users to deploy MySQL clusters with both asynchronous and group replication topology. This release includes various stability improvements and bug fixes, getting the Operator closer to the General Availability stage. Version 0.9.0 of the Percona Operator for MySQL is still a tech preview release, and it is not recommended for production environments. As of today, we recommend using Percona Operator for MySQL based on Percona XtraDB Cluster, which is production-ready and contains everything you need to quickly and consistently deploy and scale MySQL clusters in a Kubernetes-based environment, on-premises or in the cloud.

Highlights

Scheduled backups

Starting from now, the Operator supports scheduled backups, moving towards the upcoming general availability status. You can configure scheduled backups in the Custom Resource, as you do with other Percona Operators, in the backup.schedule subsection, setting the name of the backup, schedule in crontab format, as well as the backup storage, and, optionally, the retention (the number of backups to keep):

backup:
  ...
  schedule:
    - name: "sat-night-backup"
      schedule: "0 0 * * 6"
      keep: 3
      storageName: s3-us-west

See more detailed instructions on configuring scheduled backups in our documentation.

New features

• K8SPS-348: Scheduled backups are now supported in addition to on-demand ones
• K8SPS-367: A new percona.com/delete-mysql-pvc Finalizer can be used to automatically delete Persistent Volume Claims for the database cluster Pods after the cluster deletion event (off by default)

Improvements

• K8SPS-361: Now the recommended 33061 port is used during the Group Replication bootstrap instead of the default MySQL port 3306
• K8SPS-364: Reconciling full cluster crush is now done only for the Group Replication cluster type, as it is not required for asynchronous replication clusters
• K8SPS-377: A clean-up was done in the database initialization code to avoid using the --skip-ssl option in the Operator, which was removed in MySQL 8.4

Bugs Fixed

• K8SPS-350: Remove the sslInternalSecretName Custom Resource option which was not actually used by the Operator
• K8SPS-354: Fix a bug where custom sslSecret was deleted at cluster deletion even with disabled percona.com/delete-ssl finalizer
• K8SPS-359: Fix a bug where the Operator couldn’t perform crash recovery for the Group Replication cluster if there was a leftover instance
• K8SPS-360: Fix a bug where the outdated orchestrator Services were not removed after the asynchronous cluster downscale
• K8SPS-365: Fix a bug that caused crash loop in case of MySQL version upgrade due to restarting MySQL container after adding the Pod to the cluster
• K8SPS-369 and K8SPS-373: Fix a bug where the asynchronous replication cluster was temporarily getting error status during smart update or when starting the single-Pod cluster
• K8SPS-372: Fix a bug where MySQL Pod was failing during the SmartUpdate on two-node asynchronous replication cluster
• K8SPS-388: Fix a bug where the Operator could not create ps-db-mysql and ps-db-orc StatefulSets with Resource Quota enabled (thanks to xirehat for contribution)

Deprecation and removal

• The sslInternalSecretName option is removed from the Custom Resource

Known limitations

• Both upgrade to the Operator version 0.9.0 and the appropriate database cluster upgrade can not be done in a usual way due to a number of internal changes, and require additional manual operations.
  • Upgrading the Operator can be done with this workaround
  • Upgrading the database cluster can be done by deleting and recreating it

Supported Platforms

The Operator was developed and tested with Percona Server for MySQL 8.0.40-31. Other options may also work but have not been tested. Other software components include:

• Orchestrator 3.2.6-15
• MySQL Router 8.0.40
• XtraBackup 8.0.35-31
• Percona Toolkit 3.7.0
• HAProxy 2.8.11
• PMM Client 2.44.0

Percona Operators are designed for compatibility with all CNCF-certified Kubernetes distributions. Our release process includes targeted testing and validation on major cloud provider platforms and OpenShift, as detailed below for Operator version 0.9.0:

• Google Kubernetes Engine (GKE) 1.29 - 1.31
• Amazon Elastic Container Service for Kubernetes (EKS) 1.29 - 1.32
• Minikube 1.35.0 (based on Kubernetes 1.32.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 backward compatibility offered by Kubernetes itself.

v0.8.0

Installation

Installing Percona Operator for MySQL

Percona Operator for MySQL allows users to deploy MySQL clusters with both asynchronous and group replication topology. This release includes various stability improvements and bug fixes, getting the Operator closer to the General Availability stage. Version 0.8.0 of the Percona Operator for MySQL is still a tech preview release and it is not recommended for production environments. As of today, we recommend using Percona Operator for MySQL based on Percona XtraDB Cluster, which is production-ready and contains everything you need to quickly and consistently deploy and scale MySQL clusters in a Kubernetes-based environment, on-premises or in the cloud.

Highlights

Supporting cluster-wide Operator installation

Starting from now, the Operator can be installed in multi-namespace (so-called “cluster-wide”) mode, enabling management of Percona Server for MySQL clusters across multiple namespaces from a single Operator. This functionality, already available for other Percona Operators, brings greater flexibility and efficiency to managing MySQL databases on Kubernetes.

Fixing the overloaded allowUnsafeConfigurations flag

In the previous Operator versions allowUnsafeConfigurations Custom Resource option was used to allow configuring a cluster with unsafe parameters, such as starting it with unsafe number of MySQL or proxy instances. In fact, setting this option to true resulted in a wide range of reduced safety features without the user's explicit intent.

With this release, a separate unsafeFlags Custom Resource section is introduced for the fine-grained control of the safety loosening features:

unsafeFlags:
  mysqlSize: true
  proxy: true
  proxySize: true
  orchestrator: true
  orchestratorSize: true

New features

• K8SPS-149: Custom Resource options now include customizable health checks and timeouts for HAProxy
• K8SPS-186 and K8SPS-370: Removing allowUnsafeConfigurations Custom Resource option in favor of fine-grained safety control in the unsafeFlags subsection
• K8SPS-241: Support for the cluster-wide Operator mode allowing one Operator to watch for Percona Server for MySQL Custom Resources in several namespaces

Improvements

• K8SPS-334: Finalizers were renamed to contain fully qualified domain names (FQDNs), avoiding potential conflicts with other finalizer names in the same Kubernetes environment
• K8SPS-333: improve delete-mysql-pods-in-order finalizer to take into account possible change of the primary instance in group replication
• K8SPS-340: A securityContext of the xtrabackup container can now be configured allowing administrators to define security profiles for the container
• K8SPS-43: Custom Resource status obtained with the kubectl get ps command now takes into account both group and asynchronous replication, and doesn’t report the cluster as ready if the replication is broken

Bugs Fixed

• K8SPS-366: Fix a bug where cluster deletion caused the Operator panic due to querying a non-existing Custom Resource
• K8SPS-346: Fix a bug where the cluster started with 1 node and dataset bigger than 100 GB was unable to scale up because of too short bootstrap timeout
• K8SPS-341: Fix a bug where failed backup deletion got stuck because of being blocked by the delete-backup finalizer
• K8SPS-310: TLS certificate and issuer names generated by the Operator are now aligned with other Percona Operators to streamline coherent user experience
• K8SPS-301: Fix a bug that caused multiple error messages to appear in logs on MySQL Pod deletion
• K8SPS-307: Fix a bug where updating database with SmartUpdate strategy didn’t produce log messages about updated primary Pod and about finishing the update process

Deprecation and removal

• Starting from now, allowUnsafeConfigurations Custom Resource option is deprecated in favor of a number of options under the unsafeFlags subsection. Setting allowUnsafeConfigurations won't have any effect; upgrading existing clusters with allowUnsafeConfigurations=true will cause everything under unsafeFlags set to true

• Finalizers were renamed to contain fully qualified domain names:

  • delete-mysql-pods-in-order renamed to percona.com/delete-mysql-pods-in-order
  • delete-ssl renamed to percona.com/delete-ssl
  • delete-backup renamed to percona.com/delete-backup

Supported Platforms

The Operator was developed and tested with Percona Server for MySQL 8.0.36-28.
Other options may also work but have not been tested. Other software components include:

• Orchestrator 3.2.6-12
• MySQL Router 8.0.36
• XtraBackup 8.0.35-31
• Percona Toolkit 3.6.0
• HAProxy 2.8.5
• PMM Client 2.42.0

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

• Google Kubernetes Engine (GKE) 1.27 - 1.29
• Amazon Elastic Container Service for Kubernetes (EKS) 1.27 - 1.30
• Minikube 1.33.1 (based on Kubernetes 1.30.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 backward compatibility offered by Kubernetes itself.