Page last updated:
Pivotal recommends that you upgrade to the latest version of your current minor line, then upgrade to the latest available version of the new minor line. For example, if you use an older v2.4.x version, upgrade to the latest v2.4.x version before upgrading to the latest v2.5.x version.
For product versions and upgrade paths, see the Product Compatibility Matrix.
Breaking Change: All service bindings created using MySQL for Pivotal Cloud Foundry (PCF) v2.3 or earlier use IP addresses. Any bindings created using v2.3 or earlier must be re-created before upgrading to v2.5, which requires service bindings that use DNS hostnames. For more information, see MySQL for PCF Errands.
Release Date: January 11, 2019
This release fixes the following issue:
- The issue in the interaction between the MariaDB Connector/J and the Java API. This issue prevented TLS connection for Spring Cloud Services, Scheduler for PCF, and all Spring apps that used the MariaDB Connector/J.
Changes in this release:
- Updates golang to v1.11.4 to address CVE-2018-16873
Release Date: December 19, 2018
This release has the following issue:
- There is a known issue in the interaction between the MariaDB Connector/J and the Java API, which leads to the following limitations:
- PCF deployments using the Spring Cloud Services tile or the Scheduler for PCF tile must have TLS disabled in the MySQL for PCF tile.
- If the operator chooses to enable TLS, developers cannot use the MariaDB Connector/J in their Spring apps to connect to a MySQL service instance. Pivotal recommends developers configure their apps to use the MySQL Connector/J instead of the MariaDB Connector/J.
New features and changes in this release:
- Highly Available (HA) Cluster Service Plans
- All Bindings Use DNS
- Developers Can Monitor Service Instances
- Connections Secured with TLS by Default
- Improvements for Operators
WARNING: Highly available (HA) cluster service plans are currently in beta. HA clusters are for advanced use cases only.
MySQL for PCF now supports three deployment topologies. In addition to single node and leader-follower service plans, operators can offer an HA cluster service plan. For information on how to configure an HA cluster plan, see Configure Service Plans. For information on availability criteria for each topology, see Availability Options.
Features of HA clusters include:
- Multiple deployments of HA clusters can be provisioned on demand.
- Developers can view a dashboard to see the state of each node in an HA cluster. For more information, see Monitor Node Health Using the Dashboard.
- Connections to HA clusters are secured via TLS.
- Monitoring, diagnostics, and backups are performed from a jumpbox VM.
For information on how to configure this VM,
see Configure Service Plans.
- The jumpbox VM runs a replication canary that continuously tests replication health of cluster nodes. For more information, see Replication Canary.
- Operators can run diagnostics, such as disk usage, on an HA cluster by running
mysql-diagon the jumpbox VM. For more information, see Running mysql-diag.
- Like single node and leader-follower, configuring automatic backups is required. For information on how to configure automated backups, see Configure Backups. For instructions to perform a manual backup and restore, see Backing Up and Restoring On-Demand MySQL for PCF.
While in beta, the following limitations exist for HA clusters:
- Operators are required to impose a plan quota of five or fewer instances.
- Restoring from backups is a manual process. For more information, see Restore an HA Cluster Instance.
- HA clusters cannot integrate with Vormetric Transparent Encryption for PCF.
Highly Available clusters are for advanced use cases only. In addition to higher infrastructure cost, HA clusters introduce some significant limitations that are different from running single node or leader-follower service plans. For more information, see High Availability Limitations.
Due to these limitations, Pivotal recommends that HA clusters are not shared between multiple users or apps. Service instance sharing is disabled for HA clusters. If necessary, you can still share HA clusters between multiple users or apps by creating user-provided service instances. For more information, see User-Provided Service Instances.
You should use HA clusters only when the availability criteria that leader-follower provides is not sufficient for your app.
- All services bindings use DNS hostnames instead of IP addresses. This feature was introduced in MySQL for PCF v2.4, which enabled no-rebind failovers as well as future improvements and highly available (HA) clusters.
- Developers can see metrics for their service instances using the Cloud Foundry Command Line Interface (cf CLI) Log Cache plugin. For more information about the cf CLI Log Cache plugin, see Cloud Foundry Command Line Interface (cf CLI) Log Cache plugin. For more information about metrics for MySQL for PCF, see Monitoring and KPIs.
- Connections to the database over TLS are enabled by default for each service instance. Developers no longer need to manually enable TLS. Operators can optionally disable TLS.
- Operators can configure up to nine service plans in the tile.
- Operators can mark service plans as free or paid. This feature helps developers to be aware of costs associated with certain service plans.
- Operators can configure the default idle timeout for connections to a service instance. This prevents apps from overloading the database with unnecessary connections.
Do not use.
Do not use.
The following components are compatible with this release: