You can find the source of this version on GitHub at cloudfoundry/cf-mysql-release. It was created based on the commit
- Don’t miss Changes in Manifest Generation - Important!, below.
- CF MySQL now uses MariaDB 10.0.23 and Galera 25.3.9 [#110702918]
- As an Operator, I’d like to specify a user that has read-only-access to all data [#110369648]
Supply a password for the
roadmin user in the manifest, and cf-mysql will automatically provision a user with access to read all databases in the system, but permission to write to none. You can rotate this password by redefining it in the manifest and redeploying.
- If you don’t like this, it’s easy to disable. [#112020565]
Introducing the Arbitrator
For cf-mysql administrators who are careful with their infrastructure resources, the Arbitrator feature is a new deployment topology that uses a smaller VM footprint while maintaining high availability guarantees. Unlike the old three node topology, the Arbitrator decreases spend with no impact on performance.
With cf-mysql v26, we’ve replaced one of the MySQL nodes with a lightweight Arbitrator node. Previously, the minimal HA configuration required three full-size MySQL nodes.
When using only two nodes, the safest way to respond to a network or VM incident is downtime: the nodes stop accepting traffic until they can re-establish communication. An Arbitrator helps a two node MySQL cluster avoid the possibility of a split-brain condition or downtime by participating in weighted quorum elections.
CF-MySQL scales best vertically, not horizontally. On many public clouds, large instances can be very expensive, but the Arbitrator uses a lightweight VM. By using an Arbitrator, as you scale your deployment, you spend only twice, not three times the cost required to support your applications. On AWS, we recommend a T2 small with no sacrifice in performance, see our benchmarking work below.
For new deployments, the 2+1 topology is the default. You can find instructions to generate an install manifest in the README.md, and further instructions to migrate between Single, Three, and 2+1 toplogies in the Arbitrator documentation. The instructions also cover how to migrate between each. If you follow along carefully, you won’t experience any downtime. - [#109744228], [#109744232], [#109744230], [#109744234, [#109744236], [#110772724], [#111741306], [#109748868] - You can view our results in the Benchmarking spreadsheet.
Bugfixes and Interestings
- Ensures bulk-loading data from big files using
LOAD DATA INFILEuses transactions.
- Ensures bulk-loading data from big files using
- Change default of skip_name_resolve to true [#106676160]
- As promised in the v25 release notes.
- Bugfix: Bump route-registrar libraries [#112556657]
- Bugfix: As an Operator and as a Service Author, it’d be great to keep a local copy of logs when syslog is configured [#111344064]
- Bugfix: wsrep_node_name is the same for all mysql jobs [#113135203]
- Docs fix: Document that user should wait if they encounter the monit 503 error during bootstrap [#111778592]
Changes in Manifest Generation - Important!
- As an Operator, I should be able to specify flags instead of positional args when generating a manifest [#110775864].
We’ve changed the way you create manifests considerably. The new way closely resembles how diego generates manifests. Regrettably, for those of you who do not generate manifests by updating stubs and re-generating manifests, the new manifests are significantly different than versions pre-v26.
generate-deployment-manifest script is now located in the cf-mysql-release
scripts directory. Run
./scripts/generate-deployment-manifest without argument to see help output.
- Manifest generation now requires spiff v1.0.7
If you’re the type of person who manually updates deployment manifests, we’ve unfortunately made a lot of work for you. We highly recommend you switch to generating manifests from the provided stubs each time you update
MySQL Job Spec Changes
cf_mysql.mysql.skip_name_resolveand it now defaults to true
cf_mysql.mysql.roadmin_enableddetermine if the read only user exists
roadmin_passwordis blank or
roadmin_enabledis false, the read only user will be disabled
Proxy Job Spec Changes
- Move all properties to be under the top level
cf_mysqlkey, except for
cluster_ipsnow refers to the same
cf_mysql.mysql.cluster_ipsfrom the mysql job spec
- Rename the entire
cf_mysql.proxy.arbitrator_ipproperty to tell the proxy where the arbitrator lives. This, in case you are deploying using an arbitrator, see above for details.
CF MySQL Broker Job Spec Changes
cf_mysql: broker: auth_username: auth_password: cookie_secret: max_user_connections_default: services: ssl_enabled:
Arbitrator Job Spec
- See spec file spec file for manifest properties.
- These properties are optional dependent upon whether you are deploying an arbitrator.
Acceptance Tests Errand Spec Changes
- Move all
Bootstrap Errand Spec Changes
- All properties have been moved under
Broker Registrar Errand Spec Changes
Broker Deregistrar Errand Spec Changes
You can reference this release in your deployment manifest from the
- name: "cf-mysql" version: "26" url: "https://bosh.io/d/github.com/cloudfoundry/cf-mysql-release?v=26" sha1: "43aa3449855a60b774c66cc5ab3f02caa43974dc"
Or upload it to your director with the
bosh upload-release --sha1 43aa3449855a60b774c66cc5ab3f02caa43974dc \ https://bosh.io/d/github.com/cloudfoundry/cf-mysql-release?v=26