LATEST VERSION: 1.9 - CHANGELOG
MySQL for PCF v1.9

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.

v1.9.11

Release Date: Sept 21, 2017

v1.9.10

Release Date: September 14, 2017

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

v1.9.9

Release Date: August 21, 2017

v1.9.8

Release Date: August 16, 2017

v1.9.7

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 pivotal.io/security.

v1.9.6

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:

    proxy-JOB-INDEX-p-mysql.SYSTEM-DOMAIN
    

    For example: proxy-0-p-mysql.sys.bosh-lite.com

    The new scheme is now:

    JOB-INDEX-proxy-p-mysql.SYSTEM-DOMAIN
    

    For example: 0-proxy-p-mysql.sys.bosh-lite.com

  • 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.

v1.9.5

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 pivotal.io/security.

v1.9.4

Release Date: June 2, 2017

v1.9.3

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.

v1.9.2

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 https://pivotal.io/security

v1.9.1

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.

v1.9.0

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