v1.0.0

Release highlights

This release marks the General Availability (GA) of Percona Operator for MySQL using Percona Server for MySQL with the group replication type. The asynchronous replication has the tech preview status and we don't recommend using it in production yet.

With the GA status of the Operator, you can confidently deploy and run it in production environments, benefiting from long-term maintenance and enterprise-grade reliability.

Alternatively, you may opt for 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.

This release focuses on stability and bug fixing, ensuring the Operator is ready for production use. Additionally, it introduces these improvements:

Seamless Operator lifecycle management on OpenShift OLM

The Operator images are passing official certification for OpenShift. When passed, this unlocks full support for the Operator Lifecycle Manager (OLM) so that you can install, upgrade and manage the Operator's lifecycle directly from the OpenShift console.

What this means for you:

• Simplified installation: Deploy Operators directly from the OpenShift UI with just a few clicks.
• Streamlined updates: Stay current with automatic or manual updates via OLM.
• Enterprise-grade assurance: Certified images meet Red Hat's security and compatibility standards.
• Better integration: Leverage OpenShift-native workflows for lifecycle management, RBAC, and monitoring.
• Scalable operations: Simplify cluster-wide rollouts and reduce manual overhead.

All OpenShift-related features will become available to users as soon as certification is confirmed. Whether you're a platform engineer, DBA, or architect, this advancement will bring you closer to a secure, scalable, and policy-driven infrastructure.

Streamlined custom configuration usage for backup and restore processes

In previous version we have added the ability to fine-tune backups and restores by defining xtrabackup, xbstream and xbcloud settings globally via the Custom Resource manifest, or individually via a specific backup / restore manifest.

In this release we improved how the Operator applies these settings: now individual configuration always takes precedence over global settings.

With this improvement you have maximum flexibility: you can define consistent default settings for the entire cluster, but still tailor individual backup or restore operations as needed. This way you can optimize performance, troubleshoot, or customize specific scenarios without affecting the global configuration.

Increased timeouts for read, write and clone operations inside MySQL cluster

To improve reliability of clone operations in asynchronous MySQL clusters, especially when transferring large datasets, we've increased the default timeouts for read, write and clone operations to 3600 seconds. This change helps prevent premature failures caused by network delays or slow disk I/O during large data transfers.

The following timeouts are now set to 3600s by default:

• BOOTSTRAP_CLONE_TIMEOUT
• BOOTSTRAP_READ_TIMEOUT
• BOOTSTRAP_WRITE_TIMEOUT

You can fine-tune the timeout for cloning in your custom resource (CR) using environment variables:

spec:
  mysql:
    env:
      - name: BOOTSTRAP_CLONE_TIMEOUT
        value: "3600"
      - name: BOOTSTRAP_READ_TIMEOUT
        value: "3600"
      - name: BOOTSTRAP_WRITE_TIMEOUT
        value: "3600"

This update ensures smoother provisioning and bootstrapping of new database nodes, especially in environments with large datasets or variable network conditions.

Deprecation, rename and removal

• Changed paths for example configuration files for backups and restores. They are now stored in the deploy/backup/ folder. Adjust your automation workflows with this new path, if needed.
• The Custom Resource options spec.pmm.readinessProbes and spec.pmm.livenessProbes have been renamed to the singular spec.pmm.readinessProbe and spec.pmm.livenessProbe, respectively. Please update your application configurations to use these new field names as needed.

Known limitations

If you defined several schedules for the same remote backup storage, be aware of the following limitations:

1. Retention policy conflicts. The Operator applies retention policies only to the first schedule in your configuration. For example, if you set daily backups to keep 5 copies and monthly backups to keep 3 copies, the Operator will only keep 5 total backups in storage, not 8 as you might expect. However, all backup objects will still appear in kubectl get ps-backup output.

2. Concurrent backup conflicts. When multiple schedules run simultaneously and write to the same storage path, backups can overwrite each other, resulting in incomplete or corrupted data.

To avoid these issues and ensure each schedule maintains its own retention policy, configure separate storage locations for each schedule. Refer to the documentation for more information and configuration steps.

Changelog

Improvements

• K8SPS-469 - Improved log message to display clearer and more informative error messages in case of authorization issues to a backup storage.
• K8SPS-537 - Extended the test suite for the automatic update process to include MySQL version 8.4.
• K8SPS-574 - Align readiness and liveness probe naming to be in the singular form to correspond to to the Kubernetes API structure

Fixed bugs

• K8SPS-491 - Percona Operator for MySQL now automatically generates the secrets object in the format <cluster-name>-secrets, if it's not explicitly defined in the Custom resource, preventing common startup errors.

• K8SPS-492 - Fixed the issue with the Operator sending the unsupported Error event type during the Group Replication cluster startup by sending the Warning event type instead.

• K8SPS-498 - Stopped unnecessary updates to the resourceVersion field of the cluster objects during its initialization.

• K8SPS-501 - Fixed the issue with the Operator failing to update the PVC when expanding database volumes by retrying the operation.

• K8SPS-517 - Fixed an issue that prevented MySQL clone operations from completing successfully due to a default 10-second read timeout, which caused "query interrupted" errors. This was resolved by increasing the default read/write timeouts to 3600 seconds (1 hour) for long-running operations and enhancing error handling for better reliability and debugging.

• K8SPS-518 - ConfigMap settings were fixed to ensure proper labels are applied when deploying clusters with various replication and router configurations.

• K8SPS-521 - Fixed an issue where mysql-shell would overwrite Group Replication options in my.cnf during cluster creation. The operator now parses my.cnf and explicitly passes user-defined settings (like group_replication_single_primary_mode and group_replication_paxos_single_leader) to dba.createCluster(), ensuring user customizations are respected.

• K8SPS-524 - Fixed the issue with successful backups displaying the incorrect state description. The state description field is irrelevant for successful backups and is not present.

• K8SPS-529 - Removed reconciliation of backups that entered the error state due to underlying configuration issues and keep their state for troubleshooting.

• K8SPS-533 - The individual configuration for xbcloud, xbstream and xtrabackup tools specified directly for a backup or a restore object now fully overrides any default arguments set in the cluster's custom resource.

• K8SPS-535 - Backup deletion operations no longer display an erroneous failure message when the backup is successfully removed from storage.

• K8SPS-539 - Fixed the issue with excessive CPU utilization of the ps-entrypoint.sh recovery by adding a backoff mechanism to the file existence check. This improves cluster operation in environments where CPU resources are a concern.

• K8SPS-548 - Improved Group Replication self-healing test and resolved a sporadic failure where a pod would not become ready after a full cluster crash.

• K8SPS-456,K8SPS-550 - Fixed the issue with service accounts defined for HAProxy Pods via Custom Resource not being applied.

• K8SPS-556 - Improved logging when telemetry server is unavailable by placing them to Debug level

• K8SPS-560 - Fixed the issue with scheduled backups failing due to conflicting job names when multiple backups run concurrently.

• [K8SPS...

v0.12.0

Release highlights

Full MySQL 8.4 support is now available

With this release, data-at-rest encryption is now supported for Percona Server for MySQL 8.4.

In the previous release, we have added support for Percona Server for MySQL 8.4 within the Operator. However, data-at-rest encryption was not yet available. That limitation has now been lifted, unlocking the full potential of Percona Server for MySQL’s latest major version. Check our documentation for Percona Server for MySQL 8.4-specific setup instructions.

This improvement empowers you to take full advantage of Percona Server for MySQL 8.4’s features while benefiting from seamless, automated lifecycle management provided by the Operator. Percona Server for MySQL 8.4 is now the default version for deploying a database cluster.

Ensure cluster availability with PodDisruptionBudgets

A PodDisruptionBudget (PDB) in Kubernetes helps keep your applications available during voluntary disruptions, such as deleting a deployment or draining a node for maintenance. A PDB sets a limit on how many Pods can be unavailable at the same time due to these voluntary actions.

With this release, you can now configure PodDisruptionBudgets for MySQL, HAProxy, MySQL Router, and Orchestrator Pods, thus ensuring your cluster remains available, even during disruptions or planned maintenance.

Fine-tune backup and restore operations

The Operator sets sensible defaults for backups and restores to ensure their smooth flow. If you need more control, you can fine-tune xtrabackup, xbstream, and xbcloud settings. You can do this globally via the deploy/cr.yaml Custom resource manifest or individually for a specific backup / restore operation via the respective deploy/backup.yaml or deploy/restore.yaml manifests. In either case, define your configuration in the spec.containerOptions subsection. For example:

spec:
  backup:
    storages:
      <STORAGE-NAME>:
         containerOptions:
           env:
           - name: CUSTOM_VAR
             value: "false"
           args:
             xtrabackup:
             - "--someflag=abc"
             xbcloud:
             - "--someflag=abc"
             xbstream:
             - "--someflag=abc"

Note that individual settings take precedence over the global ones. Read more about fine-tuning backups and restores and how the settings are applied in our documentation.

Monitor PMM Client health and status

Percona Monitoring and Management (PMM) is a great tool to monitor the health of your database cluster. Now you can also learn if PMM itself is healthy using probes - a Kubernetes diagnostics mechanism to check the health and status of containers. Use the spec.pmm.readinessProbes.* and spec.pmm.livenessProbes.* Custom Resource options to fine-tune Readiness and Liveness probes for PMM Client.

Define a source Pod for backups

You can now explicitly define from what MySQL instance Pod the Operator should make a backup. You can specify the Pod in the deploy/cr.yaml to apply it for all backups, both scheduled and on-demand. You can also override it for an on-demand backup in its resource manifest.

spec:
  backup:
      sourcePod: ps-cluster1-mysql-1

These options let you tailor your backup strategy to fit your organization's policies.

For asynchronous replication clusters, the Operator must know the cluster topology to run a backup. For this, either enable the Orchestrator in your deployment. Or specify the sourcePod value, if your cluster has more than one MySQL Pods.

Deprecation, rename and removal

• The .spec.initImage field has been replaced by the .spec.initContainer subsection, which follows Kubernetes best practices for defining containers that run before the main containers in a Pod. The initContainer feature is helpful for setup tasks such as:

  • Initializing data
  • Waiting for services to become available
  • Setting permissions
  • Pulling secrets or configuration files

• The default cluster name has been changed to ps-cluster1 to prevent possible conflicts if you have custom resources of both Percona Operator for MySQL based on Percona Server for MySQL and Percona XtraDB Cluster in the same namespace.

• The API version in CRD has changed from v1alpha to v1. Read more about updates in Known limitations.

Known limitations

Due to the API version change, CRD updates are currently not supported. In order to update to version 0.12.0, you must manually delete the CRDs, apply new ones and recreate the cluster. To keep the data, do the following:

• check that the percona.com/delete-mysql-pvc finalizer is not enabled in deploy/cr.yaml
• don't delete PVCs manually
• Recreate the cluster with the same name. The Operator then automatically reuses the same PVCs.

Changelog

New features

• K8SPS-400 - Improved flexibility for backups and restores via adding support for custom options for xtrabackup, xbstream, and xbcloud binaries.

• K8SPS-405 - Users can now configure the LivenessProbe for the PMM Client container, allowing for custom timeouts and improved container health checks.

• K8SPS-413 - Add ability to set resources and containerSecurityContext for init containers.

• K8SPS-480 - Added support for data-at-rest encryption for MySQL 8.4.

Improvements

• K8SPS-172 - The operator now includes logs for all haproxy manipulations, providing better visibility for operations like adding, deleting, or downscaling.

• K8SPS-269 - All Kubernetes objects created by the Operator now have appropriate labels, including the Orchestrator configmap in async clusters. This improves object filtering and grouping.

• K8SPS-417 - Added ability to define PodDisruptionBudget, which helps manage voluntary disruptions to your cluster.

• K8SPS-427 - Simplified the Custom Resource (CR) validation logic by using Kubernetes validations for CR input.

• K8SPS-464 - The Operator will now automatically set the crVersion to the Operator's current version if it is not defined by the user.

• K8SPS-466 - Added ability to set global labels and annotations for all Kubernetes objects created by the Operator.

• K8SPS-478 - Improved bootstrapper behavior to determine if incremental recovery is possible and specify it when adding new instances to the existing cluster.

• K8SPS-488 - Switched to using API version v1 in custom resource definitions

Bugs fixed

• K8SPS-371 - Added the ability to set a backup source Pod to ensure backups are made for clusters with asynchronous replication when the Orchestrator is disabled.

• K8SPS-374 - Fixed the issue with the Operator reporting the reconciliation error when an async cluster was being paused or recovered.

• K8SPS-378 - Fixed an issue where the cluster would remain in an unready state if the Orchestrator was scaled down to 1 Pod.

• K8SPS-430 - The Operator now updates TLS certificates when new Subject Alternative Names (SANs) are added to the CR.

• K8SPS-465 - Readiness and liveness probes have been added for HAProxy Pods to ensure their health.

• K8SPS-475 - Fixed an issue where the exposePrimary.labels field was incorrectly applied to the service selector. The exposed services now contain global labels together with the exposed labels and the selectors do not contain labels.

• K8SPS-494 - Fixed the issue with the constant update of the resourceVersion of the PerconaServerMySQL object after a cluster is created. The issue was caused by the Operator receiving stale objects during reconciliation, which resulted in the InnoDBClusterBootstrapped condition being set twice in every loop and constantly updating its last transition time. The Fix updates the status directly after setting the condition and waits for consistency with the API server.

Supported software

The Operator was developed and tested with the following software:

• Percona Server for MySQL 8.4.6-6
• Percona Server for MySQL 8.0.43-34
• XtraBackup 8.4.0-4
• XtraBackup 8.0.35-34
• MySQL Router 8.4.6-6
• MySQL Router 8.0.43-34
• HAProxy 2.8.15-1
• Orchestrator 3.2.6-18
• Percona Toolkit 3.7.0-2
• PMM Client 3.4.0
• Cert Manager 1.18.2

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) ...

v0.11.0

Release highlights

Support for MySQL 8.4

This release introduces support for Percona Server for MySQL 8.4.x. The Operator supports all major functionality for this latest major version except data-at-rest encryption. However, we do not recommend Percona Server for MySQL 8.4 for production environments yet.

Ensure data security with data-at-rest encryption

Data-at-rest encryption provides robust data protection by encrypting your database files on disk. Data is encrypted automatically, in real time, prior to writing to storage and decrypted when read from storage. The Operator uses the keyring_vault plugin to encrypt tablespace files and binlog. It integrates directly with HashiCorp Vault, giving you a secure and automated solution for managing encryption keys.

With this feature, you can meet your compliance requirements and protect sensitive data without the operational complexity. Learn how to configure it in our documentation.

Note that data-at-rest encryption is currently not supported for Percona Server for MySQL 8.4.x. We plan to add it in future releases.

Support for emptyDir and hostPath volumes

You can now configure the Operator to use emptyDir or hostPath volumes for MySQL Pods, in addition to persistentVolumeClaim volumes. This extends the number of use cases for using the Operator, such as configuring additional storage for the data you don't need to persist when a Pod restarts, ephemeral workloads, testing CI/CD automation against a database and more.

Note the following key points for using volume types:

• Using hostPath can be risky in production, as it ties your Pod to a specific node and can lead to data loss if the node fails.
• emptyDir is not for persistent data.
• persistentVolumeClaim is the recommended way for persistent, portable storage in Kubernetes.

Improved security for user secrets with special characters in passwords

The Operator now generates stronger passwords using the combination of uppercase and lowercase letters, digits, and special characters like ! $ % & ( ) * + , - . < = > ? @ [ ] ^ _ { } ~ #. These have been tested to ensure compatibility across SQL queries, shell scripts, YAML files, and connection strings.

The Operator excludes problematic characters such as ’ “ \ / : | ;.

When you create passwords for user secrets yourself, be sure to stick to the approved character set to ensure your services run smoothly.

Customize connection to MySQL Router via configurable ports

You can now modify existing ports for the MySQL Router service, as well as add new custom ports. This ability enables you to fine-tune the connection to your Percona Server for MySQL cluster. For example, you can separate access to the database for different applications, so that each one connects to the same MySQL Router but gets a tailored experience based on the port.

Automated volume resizing

Kubernetes supports the Persistent Volume expansion as a stable feature since v1.24. Using it with the Operator previously involved manual operations. Now this is automated, and users can resize their PVCs by just changing the value of the resources.requests.storage option in the PerconaServerMySQL custom resource.

Deprecation, rename and removal

• .spec.pmm.runtimeClassName field has been removed from the crd.yaml and code because it wasn't being used
• .spec.backup.imagePullSecrets will now be applied to the backup and restore jobs
• .spec.proxy.haproxy.runtimeClassName will be applied to the HAProxy Pods
• .spec.pmm.serverUser is removed as not used in PMM3

Changelog

New features

• K8SPS-126 - It is now possible to resize Persistent Volume Claims by patching the PerconaServerMySQL Custom Resource. Enable, volume expansion, change persistentVolumeClaim.resources.requests.storage and let the Operator do the scaling.

• K8SPS-421 - Added data-at-rest encryption support

• K8SPS-445 - Added MySQL 8.4 support

Improvements

• K8SPS-437 - Removed the spec.pmm.serverUser field as not used in PMM 3

• K8SPS-406 - Added possibility of adding custom parameters for PMM client via Custom Resource

• K8SPS-131 - Improve connection configuration by making router ports configurable

• K8SPS-265 - Added special symbols support in passwords

• K8SPS-319 - Improve labels by adding MySQL to the Operator name

• K8SPS-323 - Added support for primary Pod discovery through a Kubernetes Service (Thank you Marjus Cako for reporting this issue)

• K8SPS-336 - Added the ability to deploy the Operator with hostPath and emptyDir volume types

• K8SPS-357 - Improved cluster provisioning

• K8SPS-401 - Added examples of setting up backups on Azure into our CRs

• K8SPS-418 - Added the ability to specify the time for the Pod to shut down gracefully after receiving a termination signal before it is forcefully killed.

• K8SPS-414 - Added the ability to configure imagePullSecrets via the Custom Resource

• K8SPS-415 - Added the ability to configure runtimeClassName via the Custom Resource

• K8SPS-416 - Added the ability to configure tolerations via the Custom Resource

Bugs Fixed

• K8SPS-287 - Improved logging to include information about allowUnsafeConfigurations not set when a user tries to scale down a cluster to less than 3 Pods

• K8SPS-298 - Added an error to the logs about invalid configuration for deploying a cluster with asynchronous replication without a proxy.

• K8SPS-308 - Fixed the issue with smart update reporting errors for the cluster with async replication

• K8SPS-381 - Improved restores from Azure blob storage by removing a hardcoded slash

• K8SPS-394 - Improved the cluster behavior when a user tries to change a replication type on a running cluster. The cluster fails because this operation is not allowed on a running cluster. Added documentation with the recommended steps.

• K8SPS-396 - Improved the gr-self-healing tests by replacing assert with readiness check for chaos-daemon

• K8SPS-425 - Fixed the cluster boootstrap process for a group replication clusters with MySQL 8.4

Supported software

The Operator was developed and tested with the following software:

• Percona Server for MySQL 8.4.5-5
• Percona Server for MySQL 8.0.42-33
• XtraBackup 8.4.0-3
• XtraBackup 8.0.35-33
• MySQL Router 8.4.5-5
• MySQL Router 8.0.42
• HAProxy 2.8.15
• Orchestrator 3.2.6-17
• Percona Toolkit 3.7.0
• PMM Client 3.3.1
• Cert Manager 1.18.2

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.31 - 1.33
• Amazon Elastic Container Service for Kubernetes (EKS) 1.31 - 1.33
• OpenShift 4.15 - 4.19
• Minikube 1.36.0 (based on Kubernetes 1.33.1)

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.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.