MySQL for PCF v1.9

Release Notes


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 the following:

    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 the following:
  • 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


Note: MySQL for PCF v1.9 requires Ops Manager v1.9.0 and later.

Deprecation Notice

MySQL for PCF v1.10 will disallow LOCK TABLES for all applications. See the notice for more details.

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