These are the release notes for VMware SQL with MySQL for Kubernetes.
Software Component Versions
The VMware MySQL Operator releases support the components listed below:
VMware MySQL Operator Version |
Percona Server |
Percona XtraBackup |
1.10.0, 1.10.1 |
8.0.29 8.0.31 8.0.32 8.0.34 |
8.0.29 8.0.31 8.0.32 8.0.34 |
1.9.0 |
8.0.28 8.0.29 8.0.31 8.0.32 |
8.0.28 8.0.29 8.0.31 8.0.32 |
1.8.0 |
8.0.28 8.0.29 8.0.31 8.0.32 |
8.0.28 8.0.29 8.0.31 8.0.32 |
1.7.0, 1.7.1 |
8.0.27 8.0.28 8.0.29 8.0.31 |
8.0.27 8.0.28 8.0.29 8.0.31 |
1.6.1, 1.6.2 |
8.0.26 8.0.27 8.0.28 8.0.29 |
8.0.26 8.0.27 8.0.28 8.0.29 |
1.5.0 |
8.0.25 8.0.26 8.0.27 8.0.28 |
8.0.25 8.0.26 8.0.27 8.0.28 |
1.4.0 |
8.0.25 8.0.26 8.0.27 |
8.0.25 8.0.26 8.0.27 |
1.3.0 |
8.0.26 |
8.0.26 |
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.10.1
Release Date: November 7th, 2023
Supported Platforms
VMware SQL with MySQL for Kubernetes is intended to be used with any Kubernetes-compliant platform that is version 1.21 or newer.
Specifically, this version of VMware SQL with MySQL for Kubernetes is tested on the following platforms: - VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) - VMware Tanzu Kubernetes Grid (TKG) - Google Kubernetes Engine (GKE) - Amazon Elastic Kubernetes Service (EKS) - Red Hat OpenShift, version 4.10+
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Changes
This release addresses the following CVEs:
Version 1.10.0
Release Date: October 18th, 2023
Supported Platforms
VMware SQL with MySQL for Kubernetes is intended to be used with any Kubernetes-compliant platform that is version 1.21 or newer.
Specifically, this version of VMware SQL with MySQL for Kubernetes is tested on the following platforms: - VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) - VMware Tanzu Kubernetes Grid (TKG) - Google Kubernetes Engine (GKE) - Amazon Elastic Kubernetes Service (EKS) - Red Hat OpenShift, version 4.10+
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Upgrading to 1.10.0
- VMware SQL with MySQL for Kubernetes supports upgrading to 1.10.0 from 1.9.x.
Features
- VMware MySQL Operator 1.10.0 supports four different MySQL versions:
- 8.0.29
- 8.0.31
- 8.0.32
- 8.0.34
- Users can configure a certificate authority for an LDAP server in order to support LDAP with TLS. For more information, refer to Configure LDAP authentication.
- Users can configure a retention policy for their backups stored in an external blobstore. For more information, see Backup Retention Policy
Changes
- If a backup is deleted from the blobstore and there is a MySQLBackupLocation associated with the bucket, the operator will remove corresponding MySQLBackup objects that reference the deleted blob.
Resolved Issues
- The MySQL resource no longer shows a warning in status conditions for group replication configuration with the prefix
loose_
.
Known Issues
- S3 backups cannot exceed 50 GB: AWS limits the multipart upload to 10,000 parts per upload. The VMware MySQL Operator uses the default part size of 5MB, which results in an upper limit of 50 GB for the full backup. For more details, see Amazon S3 multipart upload limits.
- OpenShift clusters running MySQL version 8.0.29 or lower may not successfully upgrade to MySQL version 8.0.31 due to a crash that can occur during the upgrade process. Users on OpenShift should either use versions later than MySQL version 8.0.31 or use a backup to restore into a new instance running versions later than MySQL version 8.0.31.
Limitations
- VMware MySQL metrics are exposed to a metrics collector that is currently installed inside the Kubernetes cluster.
- Backups are not supported for Google Cloud Storage (GCS) 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 remove this requirement.
- Some common operations require an administrator to run
kubectl exec
to access a pod. Some examples are:
- Check for an HA instance that is not tolerant to additional members leaving the replication group.
- Persisting system variables with
SET PERSIST
or SET PERSIST_ONLY
.
- 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 S3 server-side encryption, see the AWS documentation.
- Azure Blob Storage uses server-side encryption by default.
Version 1.9.0
Release Date: September 6th, 2023
Supported Platforms
VMware SQL with MySQL for Kubernetes is intended to be used with any Kubernetes-compliant platform that is version 1.21 or newer.
Specifically, this version of VMware SQL with MySQL for Kubernetes is tested on the following platforms: - VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) - VMware Tanzu Kubernetes Grid (TKG) - Google Kubernetes Engine (GKE) - Amazon Elastic Kubernetes Service (EKS) - Red Hat OpenShift, version 4.10+
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Upgrading to 1.9.0
- VMware SQL with MySQL for Kubernetes supports upgrading to 1.9.0 from 1.8.x.
Features
- You can now customize MySQL server parameters using a ConfigMap. This release introduces a new field in the MySQL custom resource definition,
spec.customConfig.name
. For details, refer to Customizing the MySQL Server and customConfig.
- The backup storage artifact path is changed from
yyyy/mm/dd/
to mysql-<InstanceName>-<InstanceUUID>/backups/yyyy/mm/dd/
. The artifact itself continues to be named <DATETIME>-<RANDOM_STRING>-backup.xb
. Refer to Name and Location for Backup Artifacts.
- Users can enable binary log collection using a MySQLBackupSchedule resource to perform a point-in-time recovery.
- If you have configured an Azure blob service with a custom server certificate, you can now provide a certificate authority by using the field
spec.storage.azure.caBundle
in a MySQLBackupLocation object. For more details, refer to MySQLBackupLocation Property Reference.
Changes
- The MySQL general log and slow query log are located in
/var/log/mysql
instead of /var/lib/mysql
. They are disabled by default.
Resolved Issues
- You can reference a MySQL operator helm chart as a dependency in another chart.
Known Issues
- S3 backups cannot exceed 50 GB: AWS limits the multipart upload to 10,000 parts per upload. The VMware MySQL Operator uses the default part size of 5MB, which results in an upper limit of 50 GB for the full backup. For more details, see Amazon S3 multipart upload limits.
- OpenShift clusters running MySQL version 8.0.29 or lower may not successfully upgrade to MySQL version 8.0.31 due to a crash that can occur during the upgrade process. Users on OpenShift should either use versions later than MySQL version 8.0.31 or use a backup to restore into a new instance running versions later than MySQL version 8.0.31.
- The MySQL resource mistakenly shows a warning in status conditions for group replication configuration with the prefix
loose_
.
Limitations
- VMware MySQL metrics are exposed to a metrics collector that is currently installed inside the Kubernetes cluster.
- Backups are not supported for Google Cloud Storage (GCS) 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 remove this requirement.
- Some common operations require an administrator to run
kubectl exec
to access a pod. Some examples are:
- Check for an HA instance that is not tolerant to additional members leaving the replication group.
- Persisting system variables with
SET PERSIST
or SET PERSIST_ONLY
- 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 S3 server-side encryption, see the AWS documentation.
- Azure Blob Storage uses server-side encryption by default.
Version 1.8.0
Release Date: May 31st, 2023
Supported Platforms
VMware SQL with MySQL for Kubernetes is intended to be used with any Kubernetes-compliant platform that is version 1.21 or newer.
Specifically, this version of VMware SQL with MySQL for Kubernetes is tested on the following platforms: - VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) - VMware Tanzu Kubernetes Grid (TKG) - Google Kubernetes Engine (GKE) - Amazon Elastic Kubernetes Service (EKS) - Red Hat OpenShift, version 4.10+
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Features
- VMware MySQL Operator 1.8.0 supports four different MySQL versions:
- 8.0.28
- 8.0.29
- 8.0.31
- 8.0.32
- This release adds support for scaling high availability instances to more members. For more information, see Configuring MySQL Instances for High Availability.
- There is a new MySQL user named
mysql-admin
that can connect externally and perform administrative tasks. See Accessing VMware SQL with MySQL for Kubernetes Instances.
- Port 3307 can now be accessed on the Kubernetes service to explicitly connect to read-only members of a HA instance.
Resolved Issues
- MySQL instances can now be deleted with a foreground cascading deletion.
Known Issues
- Backups fail to sync from the blobstore to the Kubernetes cluster when the associated MySQLBackupLocation has no bucket path or a bucket path set to
/
.
- S3 backups cannot exceed 50 GB: AWS limits the multipart upload to 10,000 parts per upload. The VMware MySQL Operator uses the default part size of 5MB, which results in an upper limit of 50 GB for the full backup. For more details, see Amazon S3 multipart upload limits.
- OpenShift clusters running MySQL version 8.0.29 or lower may not successfully upgrade to MySQL version 8.0.31 due to a crash that can occur during the upgrade process. Users on OpenShift should either use MySQL version 8.0.31+, or use a backup to restore into a new instance running MySQL version 8.0.31+.
Limitations
- VMware MySQL metrics are exposed to a metrics collector that is currently installed inside the Kubernetes cluster.
- Backups are not supported for Google Cloud Storage (GCS) 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 remove 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.
- Persisting system variables with
SET PERSIST
or SET PERSIST_ONLY
- 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 S3 server-side encryption, see the AWS documentation.
- Azure Blob Storage uses server-side encryption by default.
- You cannot reference a MySQL operator helm chart as a dependency in another chart.
Version 1.7.1
Release Date: April 5th, 2023
Supported Platforms
VMware SQL with MySQL for Kubernetes is intended to be used with any Kubernetes-compliant platform that is version 1.21 or newer.
Specifically, this version of VMware SQL with MySQL for Kubernetes is tested on the following platforms: - VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) - VMware Tanzu Kubernetes Grid (TKG) - Google Kubernetes Engine (GKE) - Amazon Elastic Kubernetes Service (EKS) - Red Hat OpenShift, version 4.10+
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Changes
- Release 1.7.1 is included in the VMware Tanzu Data Services package version 1.7.1:
registry.tanzu.vmware.com/packages-for-vmware-tanzu-data-services/tds-packages:1.7.1
. For more information see Installing using the Tanzu CLI.
- This release addresses CVE-2022-41723.
Resolved Issues
- The base image for the operator image has been fixed from Ubuntu 18.04 LTS to Ubuntu 20.04 LTS.
- The carvel PackageInstall installation now allows the PackageInstall/App to be created in a “package” namespace which can be different from the “template” namespace where the namespace-scoped resources will be created.
- Upgrading the MySQL Operator using the Tanzu CLI will not result in the instances being stuck in a
Pending
state anymore.
Known Issues
-
Backups fail to sync from the blobstore to the Kubernetes cluster when the associated MySQLBackupLocation has no bucket path or a bucket path set to ‘/’.
-
S3 backups cannot exceed 50 GB: AWS limits the multipart upload to 10,000 parts per upload. The VMware MySQL Operator uses the default part size of 5MB, which results in an upper limit of 50 GB for the full backup. For more details, see Amazon S3 multipart upload limits.
- OpenShift clusters running MySQL version 8.0.29 or lower may not successfully upgrade to MySQL version 8.0.31 due to a crash that can occur during the upgrade process. Users on OpenShift should either use MySQL version 8.0.31, or use a backup to restore into a new instance running MySQL version 8.0.31.
Limitations
- VMware MySQL metrics are exposed to a metrics collector that is currently installed inside the Kubernetes cluster.
- Backups are not supported for Google Cloud Storage (GCS) 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 remove 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 S3 server-side encryption, see the AWS documentation.
- Azure Blob Storage uses server-side encryption by default.
- You cannot reference a MySQL operator helm chart as a dependency in another chart.
Version 1.7.0
Release Date: March 9th, 2023
Supported Platforms
This version of VMware SQL with MySQL for Kubernetes is supported on the following platforms:
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Features
- VMware MySQL Operator 1.7.0 supports four different MySQL versions:
- 8.0.27
- 8.0.28
- 8.0.29
- 8.0.31
- This release adds support for Azure backup locations. For details, see Azure Configuration
- This release adds Red Hat Openshift to the supported platforms.
Changes
- Release 1.7.0 changes the product name from VMware Tanzu SQL with MySQL for Kubernetes to VMware SQL with MySQL for Kubernetes.
- The instance image changed from
tanzu-mysql-instance
to mysql-instance
.
- The operator image changed from
tanzu-mysql-operator
to mysql-operator
.
- The helm chart changed from
tanzu-mysql-operator-chart
to vmware-sql-with-mysql-operator
.
- The helm chart is published with a new media type:
application/vnd.cncf.helm.chart.content.v1.tar+gzip
. Users should use helm version 3.8.x or higher where OCI support is enabled by default.
- The base image for the operator and instance images has been changed from Ubuntu 18.04 LTS to Ubuntu 20.04 LTS.
- Release 1.7.0 is included in the VMware Tanzu Data Services package version 1.7.0:
registry.tanzu.vmware.com/packages-for-vmware-tanzu-data-services/tds-packages:1.7.0
. For more information see Installing using the Tanzu CLI.
Resolved Issues
- This release addresses the following CVEs:
- MySQL goes into a
Pending
state when the statefulset is owned by a separate controller rather than a Running
state.
- Restores now honor a custom CA bundle that has been specified within the MySQLBackupLocation object.
- Backups can be taken consistently regardless of whether the backup location is using a custom CA bundle.
- The MySQL Operator no longer panics when attempting to sync backups from an invalid backup location endpoint.
- Synced backups are no longer created with a failed status.
- The S3 bucket path in a backup location no longer requires a trailing slash.
- The MySQL Operator should upgrade without upgrading the instances when upgrading through the Tanzu CLI.
- This fix will only be observable when upgrading from 1.7.0 to the next version.
Known Issues
- Backups fail to sync from the blobstore to the Kubernetes cluster when the associated MySQLBackupLocation has no bucket path or a bucket path set to
/
.
- S3 backups cannot exceed 50 GB: AWS limits the multipart upload to 10,000 parts per upload. The VMware MySQL Operator uses the default part size of 5MB, which results in an upper limit of 50 GB for the full backup. For more details, see Amazon S3 multipart upload limits.
- OpenShift clusters running MySQL version 8.0.29 or lower may not successfully upgrade to MySQL version 8.0.31 due to a crash that can occur during the upgrade process. Users on OpenShift should either use MySQL version 8.0.31, or use a backup to restore into a new instance running MySQL version 8.0.31.
Limitations
- VMware MySQL metrics are exposed to a metrics collector that is currently installed inside the Kubernetes cluster.
- Backups are not supported for Google Cloud Storage (GCS) 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 remove 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 S3 server-side encryption, see the AWS documentation.
- Azure Blob Storage uses server-side encryption by default.
- Upgrading the MySQL Operator using the Tanzu CLI will result in the instances being stuck in a
Pending
state. Users must complete the upgrade for each MySQL instance for the instances to reach a Running
state.
- You cannot reference a MySQL operator helm chart as a dependency in another chart.
Version 1.6.2
Release Date: December 20th, 2022
Supported Platforms
This version of Tanzu MySQL is supported on the following platforms:
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Resolved Issues
- This release addresses the following CVEs:
Known Issues
- Backups fail to sync from the blobstore to the Kubernetes cluster when the associated MySQLBackupLocation has no bucket path or a bucket path set to ‘/’.
- Backups fail to sync from the blobstore to the Kubernetes cluster when the associated MySQLBackupLocation has no bucket path or a bucket path set to
/
.
-
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:
Limitations
- The Tanzu SQL release supports Helm 3.6.3 and lower, or Helm 3.7.1 and later. Helm 3.7.0 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 remove 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.
- You cannot reference a MySQL operator helm chart as a dependency in another chart.
Version 1.6.1
Release Date: September 29th, 2022
Supported Platforms
This version of Tanzu MySQL is supported on the following platforms:
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Features
-
Tanzu MySQL Operator 1.6.1 supports four different MySQL versions:
- 8.0.26
- 8.0.27
- 8.0.28
- 8.0.29
-
Release 1.6.1 is included in the VMware Tanzu Data Services package version 1.4.0: registry.tanzu.vmware.com/packages-for-vmware-tanzu-data-services/tds-packages:1.4.0
. For more information on installing Tanzu MySQL using the Tanzu CLI, refer to Installing using the Tanzu CLI.
-
This release changes the field spec.storage.caBundle
to spec.storage.s3.caBundle
, to create the ability to configure a CA bundle for storage endpoints using custom TLS certificates. For details, refer to Tanzu MySQL Property Reference.
Changes
- This version updates the minimum supported Kubernetes version to 1.21+.
Known Issues
- Backups fail to sync from the blobstore to the Kubernetes cluster when the associated MySQLBackupLocation has no bucket path or a bucket path set to ‘/’.
- Backups fail to sync from the blobstore to the Kubernetes cluster when the associated MySQLBackupLocation has no bucket path or a bucket path set to
/
.
- 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:
Limitations
- The Tanzu SQL release supports Helm 3.6.3 and lower, or Helm 3.7.1 and later. Helm 3.7.0 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 remove 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.
- You cannot reference a MySQL operator helm chart as a dependency in another chart.
Version 1.6.0 (RETRACTED)
Release Date: September 21st, 2022
Version 1.5.0
Release Date: June 8th, 2022
Supported Platforms
This version of Tanzu MySQL is supported on the following platforms:
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Features
- Tanzu MySQL Operator 1.5.0 supports four different MySQL versions:
- 8.0.25
- 8.0.26
- 8.0.27
- 8.0.28
-
This release adds backup status to the MySQL status. The user can now view the status of the last backup with .status.backups.lastCreated
. The user can also view the status of the last successful backup with .status.
-
Release 1.5.0 updates the VMware Tanzu Data Services package to version 1.2.0: registry.tanzu.vmware.com/packages-for-vmware-tanzu-data-services/tds-packages:1.2.0
. The TDS package 1.2.0 includes both Tanzu MySQL and Tanzu Postgres releases. For more information on installing Tanzu MySQL using the Tanzu CLI, refer to Installing using the Tanzu CLI.
Version 1.4.0
Release Date: May 5th, 2022
Supported Platforms
This version of Tanzu MySQL is supported on the following platforms:
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Features
- Tanzu MySQL Operator 1.4.0 supports three different MySQL versions:
- This release introduces a new resource,
mysqlVersion
, that manages the Operator’s supported MySQL versions, and instance upgrade behaviors. Users can list supported MySQL versions by using kubectl get mysqlVersion
. For more details see Selecting the Tanzu MySQL Version.
- Users on Tanzu Operator 1.4.0 can upgrade individual MySQL instances from one version to another. The upgrade can use one of the three supported MySQL versions. For information on the upgrade steps see Upgrade an Instance.
- To assist with instance updates and upgrades, this release introduces three new columns in the output of the
kubectl get mysql
command. The new columns are DB VERSION
, UPDATE STATUS
and USER ACTION
. For more information see Updating Instances and Upgrading MySQL Instances.
- Upgrading to the new Tanzu Operator 1.4.0 will not disrupt currently running instances that were created by an older Tanzu operator. Users have the flexibility to plan their individual instance upgrades and updates during a later convenient time.
- Users on Tanzu Operator 1.4.0 can also setup individual instances to automatically upgrade to a higher MySQL version, that will be supported by a future Operator, to protect the instances against CVEs. User can specify
mysql-latest
to keep an instance automatically upgraded to the latest supported version. For more information, see Tanzu MySQL CRD Property Reference.
- This release adds Amazon Elastic Kubernetes Service (EKS) to the supported Platforms.
Changes
- This release renames the
VERSION
column of the command output kubectl get mysql
to TANZU VERSION
.
- The
spec.version
property is deprecated and replaced with spec.mysqlVersion.name
.
- This release removes the Helm chart value
defaultInstanceVersion
. On Operator upgrade, remove this key from the Helm overrides file, or use the command line option --reset-values
.
Resolved Issues
- This release addresses the following CVEs:
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:
Limitations
- The Tanzu SQL release supports Helm 3.6.3 and lower, or Helm 3.7.1 and later. Helm 3.7.0 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 remove 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.3.0
Release Date: February 18th, 2022
Supported Platforms
This version of Tanzu MySQL is supported on the following platforms:
Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.
Features
Changes
-
This release relaxes a requirement that all tables must have primary keys. Now only HA instances require primary keys or equivalent non-null unique keys, and single-node instances have no such requirement.
-
Release 1.3.0 improves secure defaults by restricting MySQL connections from using insecure, deprecated TLSv1.0 and TLSv1.1 protocols. From this release, only TLSv1.2 and TLSv1.3 connections are supported.
Resolved Issues
- This release addresses a vulnerability CVE-2020-14040 in the mysqld_exporter process.
- In certain scenarios, kubectl validation errors were being repeated. This issue has been resolved, and the user is presented with a single list of validation errors.
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:
Limitations
- The Tanzu SQL release supports Helm 3.6.3 and lower, or Helm 3.7.1 and later. Helm 3.7.0 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 remove 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.2.0
Release Date: November 5, 2021
Supported Platforms
This version of Tanzu MySQL is supported on the following platforms:
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:
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 remove 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.
- VMware MySQL Operator now requires installing Cert Manager before creating or updating new instances. For more details, see Installing the Operator.
- VMware MySQL Operator 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 VMware MySQL Operator 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
- This release addresses a vulnerability CVE-2020-14040 in the mysqld_exporter process.
- [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 VMware MySQL Operator 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 VMware MySQL Operator 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:
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 remove 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 SQL with MySQL for Kubernetes. For an overview of this product, see About VMware MySQL Operator.
Features
-
MySQL for Kubernetes Operator: VMware SQL with MySQL for Kubernetes implements the Kubernetes Operator pattern to provision and manage on-demand Tanzu MySQL instances. VMware MySQL Operator supports single-node MySQL database instances.
For more information about VMware MySQL Operator features and compatibility, see Overview. For information about VMware MySQL Operator 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 VMware MySQL Operator Operator. This simplifies the installation process while maintaining flexibility in configuration. For information about how to install the VMware MySQL Operator Operator, see Installing the Operator.
-
Backup and Restore: VMware MySQL Operator 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: VMware MySQL Operator 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 VMware MySQL Operator instance.
To see all MySQL server settings configured, follow the procedure in (Optional) Verify MySQL Server Settings.
-
MySQL credential management: VMware MySQL Operator 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 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 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:
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 remove 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.