Release Notes

These are the release notes for VMware Tanzu™ SQL with MySQL for Kubernetes.

Software Component Versions

The Tanzu MySQL for Kubernetes releases support the components listed below:

Tanzu MySQL for Kubernetes Version	Percona Server	Percona XtraBackup
1.2.0	8.0.26	8.0.26
1.1.0	8.0.25-15	8.0.25-17
1.0.0	8.0.22–13	8.0.23–16

IMPORTANT: VMware does not support deployments that have been modified by adding layers to the packaged Docker images, or deployments that reference images other than the VMware MySQL Operator. VMware does not support changing the contents of the deployed containers and pods in any way.

Version 1.2.0

Release Date: November 5, 2021

Supported Platforms

This version of Tanzu MySQL is supported on the following platforms:

• VMware Tanzu Kubernetes Grid Integrated Edition (TKGI), version 1.9.x - 1.12.x.
• VMware Tanzu Kubernetes Grid (TKGm) on AWS, version 1.2.x - 1.4.x.
• Google Kubernetes Engine (GKE)
• Kubernetes version 1.19+

Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.

Features

• This release supports Percona Server 8.0.26, Percona XtraBackup 8.0.26, and MySQL Router 8.0.26.
• Users can now configure PVC retention policies. When deleting an instance now the PVCs can be automatically garbage collected by Kubernetes. By default, PVCs will be retained unless the user configures the retention policy.
• Pods running the MySQL Operator, MySQL proxies and MySQL database instances now conform to the "Restricted Pod Security" standard. For more details see Restricted in the Kubernetes documentation.

Security

• The Tanzu MySQL Operator 1.2.0 now uses a default self-signed ClusterIssuer and creates a default secret when users do not configure their own TLS secrets. For details see Using the Default provided TLS in the Configuring TLS for MySQL Instances page.
• Users can now configure a custom CA authority for the Tanzu MySQL Operator. For details see Configuring a Custom TLS Issuer
• The Tanzu MySQL 1.2.0 Operator automatically refreshes instance TLS certificates when the user renews a private TLS key.
• When a Tanzu MySQL instance is deleted, all TLS secrets related to that instance are also deleted.
• The Tanzu MySQL Operator 1.2.0 automatically recreates any MySQL instance secrets that are accidentally deleted.
• With this release, when users update TLS secrets or certificates, the MySQL instances refresh their TLS configuration without any pod restart.

HA enhancements

• Users can now specify database and proxy pod affinity and tolerations, to schedule pods according to node preference. For details on the CRD properties for affinity and tolerations, see Tanzu MySQL CRD Property Reference.

Resolved Issues

• This release addresses a vulnerability CVE-2020-14040 in the mysqld_exporter process.
• The Tanzu MySQL Operator 1.2.0 can now create 1.0.0 Tanzu MySQL instances: New Tanzu MySQL 1.0.0 instances, or existing 1.0.0 instances that restart, do not require an upgrade to the latest Tanzu MySQL version.
• Proxy connection limitation: The proxy in an HA instance will no longer block further connections after 100 failed connection attempts.
• imagePullSecretName no longer required for restores: MySQLRestore required imagePullSecretName to be provided in the instanceTemplate. MySQLRestore now defaults to using the imagePullSecretName that is configured in the Helm chart if the user does not provide the secret.

Known Issues

• S3 backups cannot exceed 50 GB: AWS limits the multipart upload to 10,000 parts per upload. The Tanzu MySQL default part size is 5MB, which results in an upper limit of 50 GB for the full backup. For more details, see Amazon S3 multipart upload limits.

• The following CVEs exist in this release:

  • CVE-2022-25235
  • CVE-2022-25236
  • CVE-2022-24407
  • CVE-2021-3538

Limitations

• The Tanzu SQL release supports Helm 3.6.3 and lower. Helm 3.7.x is not supported.
• Tanzu MySQL metrics are exposed to a metrics collector that is currently installed inside the Kubernetes cluster.
• Backups are only supported on S3-compatible blobstores that support the S3 ListObjectsV2 API. Notably, Google Cloud Storage (GCS) does not support this API in its S3-compatibility mode.
• To rotate MySQL system account passwords, you must manually restart the pods. For details, see Rotating MySQL Credentials.
• TLS is required for external connections to the database. There is no supported option to disable this requirement.
• Some common operations require an administrator to run kubectl exec to access a pod. Some examples are:
  • Checking for an HA instance that is not tolerant to additional members leaving the replication group.
  • Configuring schemas and users for an application.
• Backups are unencrypted. Enable S3 server-side encryption and ensure that the MySQLBackupLocation object is configured with a secure endpoint (spec.endpoint should begin with https://). For more information about server-side encryption, see the AWS documentation.

Version 1.1.0

Release Date: August 17, 2021

Features

• Release 1.1.0 supports MySQL Server 8.0.25. For details on MySQL Server 8.0.25 see MySQL Release Notes and Percona Server Release Notes.
• Release 1.1.0 supports Percona XtraBackup 8.0.25. For details on Percona XtraBackup 8.0.25 see Percona XtraBackup Release Notes.
• Tanzu MySQL instances are now created with a version number. Users may specify the spec.version field in the instance definition to specify which Tanzu MySQL version to deploy. Users can now list instances by version number. For more details, see List Instances By Version.
• When installing Tanzu MySQL, users can specify a default version for new Tanzu MySQL instances. For more details, see Installing the Operator.
• Tanzu MySQL for Kubernetes now requires installing Cert Manager before creating or updating new instances. For more details, see Installing the Operator.
• Tanzu MySQL for Kubernetes instances now expose Prometheus compatible metrics endpoints. Metrics are secured behind a self-signed TLS certificate. For more details see Monitoring MySQL Instances in Kubernetes.
• This release supports an additional auto-recovery feature: an HA cluster that loses quorum can now recover its state.
• Customers can now upgrade from a previous release to a new release. For more information on the process, see Upgrading MySQL Instances.
• This release prevents the users from making the following changes:
  • Users are prevented from scaling an HA instance to a single-node instance.
  • This release now displays an error when the user attempts to change the field storageClassName.
  • This release now displays an error when the user attempts to reduce storageSize on a running MySQL instance.
  • Users are prevented from downgrading MySQL instances to a lower version.

Changes

• instanceImage has been deprecated and removed from the Tanzu MySQL for Kubernetes Helm chart. This release introduces two new chart values, registry and defaultInstanceVersion. Users should specify registry: <my.private-registry> in their values-override.yaml. For more details, see Installing the Tanzu SQL for Kubernetes Operator.
• imagePullSecret has been renamed to imagePullSecretName for the Helm chart and the MySQL resource, and it's now optional. Users who are maintaining a deployment file for the object should rename the field or drop the field entirely. If omitted, the imagePullSecretName will default to the Helm chart setting.
• Users can now alter spec.storageSize in a MySQL object to scale up the PV (Persistent Volume), if the underlying storage class supports onlineVolumeExpansion. See Scale storageSize.
• Before installing the Tanzu MySQL operator, this release now requires cert-manager installation. For details, see Prerequisites for Installing via the Tanzu Network Registry.

Resolved Issues

• [177801601] - Users are now prevented from scaling down an existing HA cluster to a single node instance. If users set the spec.highAvailability.enabled to false in a running HA cluster, the operation fails and returns an error.
• [177369907] - When a user creates a backup with spec.storageArtifactName, when the backup starts, thetimeStarted is now correctly updated.
• [177648443] - The Tanzu MySQL for Kubernetes Operator now checks that the DNS name resolution is consistent before repairing an offline cluster.
• [177801601] - Scaling down an HA instance to a single node is prevented by the Tanzu MySQL for Kubernetes Operator.
• [177069136] - During an HA instance initialization, the proxy container starts only after all Tanzu MySQL HA instances are fully initialized.

Known Issues

• Existing or new 1.0.0 Tanzu MySQL instances require an upgrade: New Tanzu MySQL 1.0.0 instances, or existing 1.0.0 instances that restart, do not reach a Running state. The 1.1.0 Tanzu MySQL Operator tries to grant permissions to the performance_schema.keyring_component_status system table that is introduced in Percona 8.0.25, and does not exist in Percona 8.0.22 and the 1.0.0 instances. As a workaround, upgrade existing 1.0.0 Tanzu MySQL instances to 1.1.0, and avoid creating new 1.0.0 instances.

• Proxy connection limitation: The proxy in an HA instance supports up to 100 connection errors from the same source IP. When the limit is reached, the proxy does not process any further connection requests. For a workaround, restart the proxy pod in order to reset the connection error counter.

• imagePullSecretName required for restores: MySQLRestore requires imagePullSecretName to be provided in the instanceTemplate.

• S3 backups cannot exceed 50 GB: AWS limits the multipart upload to 10,000 parts per upload. The Tanzu MySQL default part size is 5MB, which results in an upper limit of 50 GB for the full backup. For more details, see Amazon S3 multipart upload limits.

• The following CVEs exist in this release:

  • CVE-2022-25235
  • CVE-2022-25236
  • CVE-2022-24407
  • CVE-2021-3538

Limitations

• Tanzu MySQL metrics are exposed to a metrics collector that is currently installed inside the Kubernetes cluster.
• HA instances have no anti-affinity capability, so the pods of an HA instance may be scheduled to the same Kubernetes node.
• Backups are only supported on S3-compatible blobstores that support the S3 ListObjectsV2 API. Notably, Google Cloud Storage (GCS) does not support this API in its S3-compatibility mode.
• To rotate MySQL system account passwords, you must manually restart the pods. For details, see Rotating MySQL Credentials.
• TLS is required for external connections to the database. There is no supported option to disable this requirement.
• Some common operations require an administrator to run kubectl exec to access a pod. Some examples are:
  • Checking for an HA instance that is not tolerant to additional members leaving the replication group.
  • Configuring schemas and users for an application.
• Backups are unencrypted. Enable S3 server-side encryption and ensure that the MySQLBackupLocation object is configured with a secure endpoint (spec.endpoint should begin with https://). For more information about server-side encryption, see the AWS documentation.

Version 1.0.0

Release Date: April 15, 2021

This is the first generally available (GA) release of VMware Tanzu™ SQL with MySQL for Kubernetes. For an overview of this product, see About Tanzu MySQL for Kubernetes.

Features

• MySQL for Kubernetes Operator: VMware Tanzu™ SQL with MySQL for Kubernetes implements the Kubernetes Operator pattern to provision and manage on-demand Tanzu MySQL instances. Tanzu MySQL for Kubernetes supports single-node MySQL database instances.
  
  For more information about Tanzu MySQL for Kubernetes features and compatibility, see Overview. For information about Tanzu MySQL for Kubernetes architecture, see Architecture. For more information about the Kubernetes Operator pattern, see the Kubernetes documentation.

• Installation Using Helm: Kubernetes admins can use Helm to install the Tanzu MySQL for Kubernetes Operator. This simplifies the installation process while maintaining flexibility in configuration. For information about how to install the Tanzu MySQL for Kubernetes Operator, see Installing the Operator.

• Backup and Restore: Tanzu MySQL for Kubernetes automates on-demand and scheduled full physical backups using the Percona XtraBackup tool. It also automates restoring and managing backups. For more information, see Backing Up and Restoring MySQL Instances.

• Sane and Secure Server Defaults: Tanzu MySQL for Kubernetes configures MySQL server settings to optimize for security and performance. Certain server settings, like max-connections, are auto-tuned based on the compute resources and persistent storage provisioned for the Tanzu MySQL for Kubernetes instance.
  
  To see all MySQL server settings configured, follow the procedure in (Optional) Verify MySQL Server Settings.

• MySQL credential management: Tanzu MySQL for Kubernetes uses Kubernetes automation to simplify rotating MySQL user credentials. For more information, see Rotating MySQL Credentials.

• High Availability: Support for creating a high-availability cluster configuration with three members. For information, see Architecture and Configuring MySQL Instances for High Availability.

• Configure TLS: TanzuMySQL instances only accept encrypted client connections. Users can now configure a TanzuMySQL instance for TLS by creating a TLS Secret. For more information, see Configuring TLS for MySQL Instances.

• Allow off-platform connections: Users can connect to a TanzuMySQL instance from outside the Kubernetes cluster using an external load balancer. For more information, see Connect to the MySQL Server with an External IP Address in Accessing MySQL Instances.

Known Issues

• Upgrades from beta releases are not supported: Upgrades from beta releases to the VMware Tanzu™ SQL with MySQL for Kubernetes v1.0.0 release are not supported. Download and install the latest version.

• Scaling down an HA instance is not supported: Creating an HA instance and scaling back to a single pod is not supported and may incur data loss. The VMware Tanzu™ SQL with MySQL for Kubernetes operator does not prevent you from changing the property, and changing the property will result in unknown behavior. If the pods for an HA instance crash while the cluster and its metadata are still being created, the cluster may not recover automatically.

• Pods may restart when creating a HA instance: Proxy pods may spontaneously restart while the cluster is being initialized.

• S3 backups cannot exceed 50 GB: AWS limits the multipart upload to 10,000 parts per upload. The Tanzu MySQL default part size is 5MB, which results in an upper limit of 50 GB for the full backup. For more details, see Amazon S3 multipart upload limits.

• The following CVEs exist in this release:

  • CVE-2022-25235
  • CVE-2022-25236
  • CVE-2022-24407

Limitations

• HA instances have no anti-affinity capability, so the pods of an HA instance may be scheduled to the same Kubernetes node.
• Backups are only supported on S3-compatible blobstores that support the S3 ListObjectsV2 API. Notably, Google Cloud Storage (GCS) does not support this API in its S3-compatibility mode.
• Changing spec.storageSize in a MySQL object to scale the PersistentVolume is not supported. See Scale storageSize for a workaround that expands the PersistentVolume.
• To rotate MySQL system account passwords, you must manually restart pods. For details, see Rotating MySQL Credentials.
• TLS is required for external connections to the database. There is no supported option to disable this requirement.
• Some common operations require an administrator to run kubectl exec to access a pod. Some examples are:
  • Checking for an HA instance that is not tolerant to additional members leaving the replication group.
  • Configuring schemas and users for an application.
• Backups are unencrypted. Enable S3 server-side encryption and ensure that the MySQLBackupLocation object is configured with a secure endpoint (spec.endpoint should begin with https://). For more on server-side encryption, see the AWS documentation.