LATEST VERSION: 2.1 - CHANGELOG

Release Notes

v1.8.11

Release Date:

This is the last planned release of MySQL for PCF 1.8. The support period for version 1.8 has expired. To stay up-to-date with the latest software and security updates, please plan to upgrade to MySQL for PCF version 1.9 or greater.

  • Change the Interruptor’s default setting to OFF.

    For a year, MySQL for PCF has included the Interruptor. It’s a protective mechanism which stops a node from automatically rejoining the cluster if doing so may 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 wish 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.

  • 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

  • Updated stemcell to 3363.29. This security upgrade resolves the following:

For more information, see pivotal.io/security.

v1.8.10

Release Date: June 22, 2017

  • 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. Thus, MySQL for PCF now has separate configuration, similar to 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.

  • Updated stemcell to 3312.29. This security upgrade resolves the following:

    For more information, see pivotal.io/security.

v1.8.9

Release Date: June 2, 2017

v1.8.8

Release Date: May 19, 2017

  • 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 might be due to an issue where the default probe timeout is too long while running under IPsec, and should be reduced. Version 1.8.8 of MySQL for PCF allows you to reduce the New Cluster Probe Timeout in the MySQL server configuration page. For more information, see Options and Features.
    • 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.8.7

Release Date: April 27, 2017

  • 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.
  • Note: The title of the tile will now appear as “MySQL for PCF,” not simply “MySQL.”

Additional information can be found at https://pivotal.io/security

v1.8.6

Release Date: April 3, 2017

  • Updated nokogiri to v1.7.1. This is a security upgrade that resolves the following:
  • Updated stemcell to 3263.22. This is a security upgrade that resolves the following:

Additional information can be found at https://pivotal.io/security

v1.8.5

Release Date: March 10, 2017

  • Bug fix: Changed the value of wsrep_max_ws_rows to 0 to prevent MariaDB bug MDEV-11817 from affecting DDLs.
  • Bug fix: The server variable, innodb_large_prefix, can be disabled via the Advanced Options configuration pane. This allows operators to avoid application errors due to MDEV-12210, a bug in MariaDB 10.1.18. Please see the documentation on cluster configuration for more information. This option will not be necessary in p-mysql 1.9 and greater.
  • Bug fix: We fixed a condition in which a spontaneously rebooted VM may not automatically rejoin the cluster.
  • Updated stemcell to 3263.21. This is a security upgrade that resolves the following:

v1.8.4

Release Date: February 24, 2017

  • Updated stemcell to 3263.20. This is a security upgrade that resolves the following:
  • Bug fix: Also addresses a minor issue in which the Operator cannot specify an IP address as the binding credentials host. Previously, this was restricted only to fully-qualified hostnames.

v1.8.3

Release Date: February 9, 2017

  • Bug fix: Addresses an issue in which rejoin-unsafe and bootstrap errands fail to run properly.

v1.8.2

Release Date: January 26, 2017

  • Updated stemcell to 3263.17, which is a routine patch update to address medium and low security vulnerabilities.

Additional information can be found at https://pivotal.io/security

v1.8.1

Release Date: December 16, 2016

  • Updated stemcell to 3263.14. This is a security upgrade that resolves the following:
  • Bug fix: Introduced a configurable startup timeout, which addresses an issue where high-traffic databases may appear as failing upon restart. See the ‘advanced configuration’ pane to update.

Additional information can be found at https://pivotal.io/security

v1.8.0

Release Date: December 7, 2016

  • Important Change: This release requires OpsManager v*1.8* or higher.
  • MariaDB has been updated to v10.1.18 and Galera to v25.3.18.
  • AWS Multi-AZ support: p-mysql 1.8.0 now balances across availability zones if provisioned with a network that has multiple subnets.
  • Multiple service plans

Note: On upgrade from a version of MySQL for PCF that offered only a single plan, the default plan will be renamed. Regardless of the name of the previous plan (e.g., 100mb-dev), the plan will now be named, pre-existing-plan. It’s not possible to automatically reset the plan to the former name. If you wish to retain the same plan name, it’s fine to edit that plan name before clicking Apply Changes when upgrading to MySQL for PCF v1.8.0. See the documentation for more information.

  • New Feature: bosh bootstrap errand

  • New Advanced Options settings page

    • Skip reverse DNS resolution when accepting connections

      This option improves performance, and is only necessary when restricting access by hostname, which is not required in typical MySQL for PCF installations.

    • Includes the option to enable a read-only user.

    • Quota Enforcer check frequency is now configurable.

  • Logging Changes:

    • Server Audit and replication debug logging can now be enabled in the Advanced Options settings page.
    • MySQL job logs are kept local on the VM, in addition to sent to syslog if configured.
    • Binary logs are now enabled and rotated automatically by the system.
    • Plus a host of debug log changes have been added to aid in diagnosis efforts.
  • MySQL Server configuration changes:

    • XA Transactions are now explicitly disallowed.
    • New service bindings and keys will not be able to lock tables.

      XA Transactions and table-level locks are not compatible with our HA technology.

      Note: Deprecation Notice: This release does not remove the privilege to lock tables from existing bindings, so it won’t break any applications that are currently deployed.

  • Backups:

    • New feature: Backing up all nodes

      In the Backups configuration pane, there’s now an option to take backups from all MySQL nodes. This feature protects your users from data loss in the case that some nodes have different data than the others.

    • Automated backups can now additionally target a Ceph back-end storage service or direct to another host via SCP.

    • Operator can now override the default number of open files while taking backups.

  • New Protections:

    We’ve discovered a rare condition where a MySQL cluster experiences a fault in replication that can result in some data loss. When this occurs, previous releases do not log the root cause of the bug. In order to best address this issue, v1.7.11 contains significant additional telemetry and several defensive features which will account for the failure condition and prevent data loss.

    Note: If any of these protections activate, it is critical that you contact Pivotal support immediately. Support will work with you to determine the nature of the cluster’s failure, and advise a suggested resolution. Additionally, contacting Support will provide us with evidence that will enable us to identify and address the root cause in the future.

    • Introducing the Replication Canary

      We’ve included a new long-running monitor, the Replication Canary. The Replication Canary continually monitors the MySQL cluster, watching for instances in which cross-cluster replication has failed. It is enabled by default, and requires an e-mail address in the Advanced Options configuration pane.

      In the event that replication has failed, the Canary performs two actions:

      • E-mail the Operator: Part of the Replication Canary’s configuration is an e-mail address, which can be directed to any Operator e-mail address, or an escalation system similar to PagerDuty.
      • Deny Access: When replication has failed, the Replication Canary will automatically disable user and applications’ ability to access the cluster via the Proxies.

      Note: Due to the serious nature of a failure in replication, both behaviors are enabled by default. During configuration, you may elect to set the Replication Canary to notify-only mode, but this is not recommended.

      • You must set the Monitoring job to 1 in the Resource Config pane, or the Replication Canary will not be enabled, regardless of configuration.
      • You must also confirm that the Elastic Runtime tile is properly configured to send e-mail. These settings are necessary for any standard Cloud Foundry configuration.

        • Ensure that the Notifications errand has been enabled.
        • Ensure that SMTP Config has been properly configured.

        If either of these are not set, configure and Apply Changes before deploying v1.7.11.

      For more information about the Replication Canary, see the monitoring documentation.

    • Introducing the Interruptor

      The MySQL nodes have new logic that, when enabled, will prevent a node from re-joining a cluster under certain conditions. This is a second level of protection against the possibility of data loss.

      For more information about the Interruptor, see the monitoring documentation.

  • Bug fix: Update broker-registrar to avoid runaway CPU condition on broker VMs.

  • Bug fix: When deployed on Ops Manager 1.7, the backup-prepare-node now requires persistent disk instead of a VM with a large amount of CPUs, RAM and ephemeral disk space.

  • Bug fix: Quota Enforcer should not block other queries from running.

  • Known Issue: Users with very large databases, depending on performance, will suffer an issue where the system fails to wait sufficiently long to the mysql server to start. This will be resolved in a coming release by introducing a tunable timeout.

  • Security fix: Switchboard no longer exposes the profiling port by default.

  • Security fix: The service broker should not use root credentials to access MySQL

  • Updated stemcell to 3263.12 to resolve the following:

    Additional information can be found at https://pivotal.io/security

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