LATEST VERSION: 1.8 - CHANGELOG
MySQL for PCF v1.8

Release Notes

v1.8.6

Release Date: 2017 April 3

  • 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

1.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:

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

1.8.3

Release Date: February 9, 2017

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

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

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

1.8.0

Release Date: December 7, 2016

  • Important Change: This release requires OpsManager version 1.8 or greater.
  • MariaDB has been updated to version 10.1.18 and Galera to 25.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. We plan to retroactively remove this permission in version 1.9.0.

  • 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, version 1.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 version 1.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

1.8.0-Edge.15

Release Date: October 26, 2016

  • Important Change: This release requires OpsManager version 1.7 or greater.
    • Per the deprecation notice first published 29 September, future releases of 1.8.0 will not install on OpsManager 1.6 or below.
  • AWS Multi-AZ support: 1.8.0-Edge.15 now balances across availability zones if provisioned with a network that has multiple subnets.
  • Updated stemcell to 3263.8. This is a security upgrade that resolves the following:

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

  • Known Issue: The bootstrap errand currently fails to run since 1.8.0-edge.9. This bug will be addressed in a future release. If the cluster needs to be bootstrapped, please follow the manual bootstrap process.

1.8.0-Edge.14

Release Date: October 14, 2016

  • Updated stemcell to 3263.7. This is a security upgrade that resolves the following:

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

1.8.0-Edge.13

Release Date: October 12 2016

  • Includes stability and bug fixes.
  • Security: We’ve made several logging fixes.

1.8.0-Edge.12

Release Date: October 10, 2016

  • Bug fix: This release fixes a bug in 1.8.0-edge.11 and 1.8.0-edge.10 where upgrading from 1.8.0-edge.9 failed on Ops Manager 1.6 when clicking the “upgrade” button.

Deprecation Notice: Future releases of p-mysql 1.8.0 will be restricted to versions of OpsManager 1.7 and greater. If you are using OpsManager 1.6 or earlier, you will need to upgrade OpsManager before upgrading to those versions of Pivotal MySQL.

1.8.0-Edge.11

Release Date: October 5, 2016

  • Do not use. Unfortunately, this release did not resolve the known issue mentioned below. Attempting to upgrade from version 1.8.0-edge.9 using Ops Manager 1.6 still results in an error.

1.8.0-Edge.10

Release Date: September 29, 2016

  • Updated stemcell to 3263.3 This is a security upgrade that resolves the following:

    • USN-3087-2
    • This also upgrades from the Linux 3.19 kernel to version 4.4.

    See https://pivotal.io/security for more information.

  • MariaDB updated to version 10.1.17 and Galera 25.3.17. This is an upgrade to a new minor release from MariaDB 10.0 to 10.1. The upgrade is automatic, and if deployed while in HA configuration will not cause downtime for applications.

  • Bug fix: Introduced a fix to the replication canary which reduces the possibility of false positives.

  • Known Issue: On Ops Manager 1.6 only, the tile fails to upgrade from p-mysql 1.8.0-edge.9. This will be fixed in a coming release. The error message returned will be similar to the following: Product 'MySQL' could not be upgraded from 1.8.0.pre.edge.9.alpha.934.9c05453 to 1.8.0.pre.edge.10. Please contact your Pivotal representative.

Deprecation Notice: Future releases of p-mysql 1.8.0 will be restricted to versions of OpsManager 1.7 and greater. If you are using OpsManager 1.6 or earlier, you will need to upgrade OpsManager before upgrading to those versions of Pivotal MySQL.

1.8.0-Edge.9

Release Date: August 29, 2016

You can find more information about these at https://pivotal.io/security.

There exists an uncommon situation 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. To best address this issue, version 1.8.0-Edge.9 contains significant additional telemetry and several defensive features which account for the failure condition and prevent data loss.

WARNING: 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 provides information that enables Pivotal to identify and address the root cause in the future.

  • Introducing the Replication Canary

    This release includes a new long-running monitor, the Replication Canary. The Replication Canary continually monitors the MySQL cluster, watching for instances where cross-cluster replication has failed. It is enabled by default and requires that you provide an email address in the Advanced Options configuration pane.

    When replication fails, the Canary performs two actions:

    • Emails the Operator: The Replication Canary configuration includes an email address which can be directed to any operator email address, or an escalation system such as PagerDuty.
    • Denies Access: When replication fails, the Replication Canary automatically disables user and applications access to the cluster through the Proxies.

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

    • 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 email. These settings are required in 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 version 1.8.0-Edge.9.

    For more information about the Replication Canary, see the Monitoring Documentation.

  • Introducing the Interruptor

    The MySQL nodes have new logic that, when enabled, 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.

  • New feature: Backing up all nodes

    In the Backups configuration pane, there is an option to take backups from all MySQL nodes. This feature protects users from data loss in when some nodes have different data than the others.

  • Logging Changes

    • MySQL job logs are kept local on the VM, in addition to being sent to syslog if configured.
    • Binary logs are now enabled and rotated automatically by the system.
    • Audit logs are now enabled, and automatically configured by the system.
      • Audit logs are not transmitted to syslog, due to the sensitive nature of the content of the audit logs.
    • Multiple debug log changes have been added to aid in diagnosis efforts.
  • XA Transactions are now disallowed.

    • XA Transactions are not compatible with HA technology.
  • Quota Enforcer is now configurable.

  • Maximum open file descriptors now default to maximum possible, over 1 million.

  • Security fix: Now includes MariaDB 10.0.24

    • Avoids a possible credential leak and fixes a minor bug.
  • Security fix: In previous releases, backups caused the MySQL VMs to log the MySQL root password, when enabled.

    Note: To change this password, see Credential Rotation.

  • Bug fix: Addresses a bug in Ops Manager 1.7.0, in which upgrading to a recent version of Pivotal MySQL causes Ops Manager to issue an internal server error.

  • Known Issue: When installed on Ops Manager, the tile identifies itself as p-mysql-1.8.0-edge.9.alpha.934.9c05453.pivotal. This is an error. It should read p-mysql-1.8.0-edge.9. This is a normal, supported release.

1.8.0-Edge.8

1.8.0-Edge.7

Release Date: June 28, 2016

  • Updated stemcell to 3232.8. This is a security upgrade that resolves the following:
  • Addresses a known issue in which recent versions of MySQL for Pivotal Cloud Foundry (PCF) 1.8.0 do not install without Internet access.
  • 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.

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

1.8.0-Edge.6

Release Date: May 18, 2016

  • Updated stemcell to 3232.4. This is a security upgrade that resolves the following:

1.8.0-Edge.5

Release Date: May 6, 2016

  • Updated stemcell to 3232.2. This is a security upgrade that resolves the following:
  • Known Issue: On PCF 1.7 only, the MySQL for PCF acceptance test errand will not work on MySQL for PCF 1.8.0-edge.1 through 1.8.0-edge.5. This will be fixed in the next release.

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

1.8.0-Edge.4

Release Date: April 8, 2016

  • Automated backups can now additionally target a Ceph back-end storage service or direct to another host via SCP.
  • New Database Configuration settings page
    • Includes the option to enable a read-only user.
    • Allows an override to activate DNS reverse name resolution.
  • Additional mysql server tuning tweaks to improve performance.
  • MariaDB updated to version 10.0.23.
  • Bug fix: Update broker-registrar to avoid runaway CPU condition on broker VMs.
  • Bug fix: Operator can now override the default number of open files while taking backups.

1.8.0-Edge.3

Release Date: March 16, 2016

1.8.0-Edge.2

Release Date: March 2, 2016

  • MySQL for PCF now skips reverse DNS resolution when accepting connections.
    • This change improves performance, and is only necessary when restricting access by hostname, which is not required in typical MySQL for PCF installations. You can override this value in the “Database Configuration” configuration pane.
  • Bug fix: Enable Operator to specify S3 region.
    • Before this configuration, uploads were limited to the S3 Standard region, 'us-east-1.’
  • See below, same security update as version 1.6.8

1.8.0-Edge.1

Release Date: January 20, 2016

  • New Feature: 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
  • MariaDB updated to version 10.0.22 and Galera 25.3.9.
Create a pull request or raise an issue on the source for this page in GitHub