Skip to content

Releases: percona/percona-server-mysql-operator

v0.12.0

23 Sep 13:32
@nastena1606 nastena1606
v0.12.0
1aae002
Compare
Choose a tag to compare
v0.12.0 Latest
Latest

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:

Read more
Assets 2
Loading

v0.11.0

01 Sep 14:47
@nastena1606 nastena1606
v0.11.0
aa5cd31
Compare
Choose a tag to compare
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:

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.

Loading

v0.10.0

06 Jun 15:10
@nastena1606 nastena1606
v0.10.0
3aaba39
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
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

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:

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.

Loading

v0.9.0

11 Feb 20:40
@fiowro fiowro
v0.9.0
4ee30de
Compare
Choose a tag to compare
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

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.

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:

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.

Loading

v0.8.0

17 Jul 10:05
@egegunes egegunes
v0.8.0
c07e4dd
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
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

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:

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.

Loading