Release Notes

Note: MySQL for PCF v1.9 is certified to work with PCF v1.9 and v1.10. For PCF v1.11, upgrade to MySQL for PCF v1.10.


Release Date: December 13, 2017


Release Date: December 8, 2017

MySQL for PCF v1.9.14 resolves several bugs, updates dependencies to maintain security, and includes changes that improve syslog and metrics.

  • Syslog Format Change

    • The components of MySQL for PCF, MySQL, Proxy, MySQL, Backups and Monitoring have been configured to observe RFC 5424 message format when sending logs to syslog.
  • New Disk Usage Metrics

  • Dependency Updates

    • Updated to stemcell 3421.32 to address low and medium vulnerabilities.
    • Updated versions of Ruby and associated libraries, and socat to avoid known vulnerabilities.
  • Bug Fixes

    • Bug fix: Fixed a rare bug which left hanging backup processes on the MySQL nodes if a client disconnects unexpectedly.
    • Bug fix: streaming-mysql-backup-tool was running as root, now it runs user vcap.
    • Bug fix: Fixed a rare bug in which the replication canary could write to a node which was not a member of the cluster, causing the cluster to be in an inconsistent state.
  • IPsec

    • Bug fix: MySQL failed to start if the node once had IPsec installed but IPsec is no longer installed.
    • Bug fix: IPsec caused mariadb_ctrl to be left in an Execution Failed state when taking time to start.


Release Date: November 3, 2017

  • New: Changed the default of innodb_flush_log_at_trx_commit to 2. This is considered safe when using Galera in clustered mode. Single node and very conservative cluster deployments might want to reset to the former default, 1. For details, see InnoDB Flush Log policy: 2.
  • Update to MariaDB 10.1.26
  • Upgrade nokogiri to 1.8.1, and rubygems to 2.6.13, to address recent Common Vulnerabilities and Exposures (CVEs)
  • Update to stemcell 3421.31 to address low and medium stemcell vulnerabilities.
  • Bug fix: Smoke tests do not run if there are no public plans.


Release Date: September 29, 2017

  • Provides a checkbox where the operator can configure table locking behavior. For more information, see the allow table locks section of the configuration page.
  • Bumped the default size of the backup VMs from 1 GB RAM / 2 CPUs to 4 GB RAM / 4 CPUs. You can customize this default in the Resource Configuration pane.
  • Bug fix: Pre-start phase logs warnings, rather than time out, when mysqld takes time to start or stop.
  • Security: Updates to rubygems 2.6.6 to address CVE-2017-0902.


Release Date: September 21, 2017


Release Date: September 14, 2017

  • Re-names package dependencies to avoid installation conflicts.
  • Updates stemcell to 3363.35, which addresses a minor logrotate issue.


Release Date: August 21, 2017


Release Date: August 16, 2017


Release Date: August 11, 2017

  • Change the Interruptor default setting to OFF.

    For a year, MySQL for PCF has included the Interruptor. It’s a protective mechanism that stops a node from automatically rejoining the cluster if doing so might delete application data. We also upgraded to MariaDB 10.1 and provided the Replication Canary to further protect application data. There have been zero instances where the Interruptor has been needed to protect application data.

    In this release, we are disabling the Interruptor because it is disruptive to normal cluster function, and requires manual operator action to restore availability. We feel confident that disabling the Interruptor in all but the most critical environments is a safe and convenient choice.

    If you want to continue using the Interruptor, make sure that “Prevent node auto re-join” is checked in the “Advanced Options” configuration pane, then hit Apply Changes.

  • Small improvements to the mysql-diag tool, now including a warning when available disk space is low.

  • Upgrades several dependencies including nokogiri 1.8.0, golang 1.8.3, xtrabackup 2.4.5, boost 1.59.0, and python 2.7.13

  • Updates stemcell to 3312.32. This security upgrade resolves USN-3265-2.

    For more information, see


Release Date: July 28, 2017

  • MySQL for PCF v1.9 has been updated with several security and performance tuning enhancements. See the architecture and configuration documentation for more details. Some important highlights:
  • The URL for the proxy has changed. The old scheme for each proxy dashboard was:


    For example:

    The new scheme is now:


    For example:

  • There is a new Advanced Configuration to set a cluster’s name before initial deployment.

  • MariaDB has been updated to v10.1.24 and Galera to v25.3.20.

  • Updated nokogiri to address CVE-2017-5029.


Release Date: June 22, 2017

  • There is a new configuration pane for syslog. Previously, MySQL for PCF used the same configuration settings as Elastic Runtime. However, some users want to send MySQL for PCF logs to destinations other than Elastic Runtime logs.

    To address this, MySQL for PCF now has a separate configuration, similar to that of RabbitMQ for PCF and Redis for PCF.

    Action required: During installation or upgrade of MySQL for PCF, you must configure or disable syslogging in the Syslog settings pane.

  • MySQL for PCF v1.9 has new backup storage options. Backup artifacts can now be stored on Google Cloud Storage or Azure Blob Storage.

  • Updated stemcell to 3312.29. This security upgrade resolves USN-3334-1.

    For more information, see


Release Date: June 2, 2017


Release Date: May 19, 2017

  • MySQL for Pivotal Cloud Foundry (PCF) now emits performance metrics which can be read via the Loggregator Firehose. This allows operators to monitor and understand performance aspects of the MySQL cluster. For more information, see Monitoring the MySQL Service.
  • Bug fixes to address issues with MySQL for PCF when the IPsec add-on is also installed:
    • Bug fix: While installing MySQL for PCF with IPsec installed, the product may fail to deploy. This may be due to an issue where the default probe timeout is too long while running under IPsec, and should be reduced. Version 1.9.3 of MySQL for PCF allows you to reduce the New Cluster Probe Timeout in the MySQL server configuration page. For more information, see MySQL Server Configuration.
    • Bug fix: A small change in the way that MySQL nodes shut down, which should better allow nodes to leave the cluster gracefully while IPsec is installed.


Release Date: April 27, 2017

  • Changed Proxy API route hostname from proxy-0-p-mysql to proxy-api-p-mysql.
  • Updated stemcell to 3312.24. This security upgrade resolves USN-3265-2.
  • Bug fix: Addressed an issue where backups were unable to store backups on AWS S3 regions that require the v4 signature.
  • Bug fix: Addressed an issue where nodes may fail to rejoin the cluster after restart. See the Rejoin Unsafe Fails Known Issue for more details.
  • Note: The title of the tile now appears as “MySQL for PCF,” not simply “MySQL.”

Additional information can be found at


Introducing mysql-diag

If configured, the monitoring VM comes with a pre-configured mysql-diag tool. This tool gives you a snapshot of the current state of the cluster.

Pivotal recommends that you always run mysql-diag before upgrade. Attempting to upgrade while a cluster is in a less-than-healthy state will not go smoothly. Always be sure that the cluster is healthy before upgrading.

The mysql-diag tool also works on earlier releases of MySQL for PCF, but it won’t be pre-installed and configured. Instructions and a download are located in the Pivotal Knowledgebase.

MySQL Server Tuning and Defaults

  • Several configuration settings have been moved to a new configuration pane, MySQL Server Configuration
  • sql_mode is now set: NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,STRICT_ALL_TABLES. sql_mode was not set on previously versions.
    • NO_ENGINE_SUBSTITUTION: Guards against applications unintentionally creating non-InnoDB tables. Previously, the current master would accept, but not replicate such tables across the cluster.
    • NO_AUTO_CREATE_USER: Prevents implicitly creating users without a password.
    • STRICT_ALL_TABLES: Enables strict mode
    • Warning: Enabling strict mode means that Applications may now start seeing errors, such as when inserting strings that are too long, or numeric values that are out of range. Previously, MariaDB silently modified the data on commit.
    • Additionally, these settings no longer allow a user to specify large indices despite innodb_large_index=ON without additionally specifying ROW_FORMAT=DYNAMIC in each table create statement. Apps that do not specify this additional clause will see an error during DDL similar to: ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.
      • The IGNORE keyword can be used when strict mode is set to convert the error to a warning.
  • wsrep_max_ws_size is set to the maximum, 2GB
  • wsrep_max_ws_rows enforces the default of 0

    • For more information about these limitations, see the documentation on transaction size.
    • There is a known issue in which this setting also affects DDLs. It will be fixed in a future release of MariaDB.
  • There is a known issue that sometimes causes the rejoin-unsafe errand to fail. See Rejoin Unsafe Fails Known Issue for more information.


Version 1.9.0 was not released. Use v1.9.1.

Create a pull request or raise an issue on the source for this page in GitHub