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.