cf-mysql/26
You can find the source of this version on GitHub at cloudfoundry/cf-mysql-release. It was created based on the commit b2ebb913
.
Release Notes¶
- Don’t miss Changes in Manifest Generation - Important!, below.
New Features
- 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
- Enable
wsrep_load_data_splitting
option [#112648647]- Ensures bulk-loading data from big files using
LOAD DATA INFILE
uses 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.
The 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 cf-mysql-release
.
Manifest Changes
MySQL Job Spec Changes
- Move
skip_name_resolve
tocf_mysql.mysql.skip_name_resolve
and it now defaults to true cf_mysql.mysql.roadmin_password
combined withcf_mysql.mysql.roadmin_enabled
determine if the read only user exists- If
roadmin_password
is blank orroadmin_enabled
is false, the read only user will be disabled
- If
port
is nowcf_mysql.mysql.port
healthcheck_port
is nowcf_mysql.mysql.healthcheck_port
max_connections
is nowcf_mysql.mysql.max_connections
innodb_buffer_pool_size
is nowcf_mysql.mysql.innodb_buffer_pool_size
cluster_ips
is nowcf_mysql.mysql.cluster_ips
max_heap_table_size
is nowcf_mysql.mysql.max_heap_table_size
tmp_table_size
is nowcf_mysql.mysql.tmp_table_size
wsrep_max_ws_rows
is nowcf_mysql.mysql.wsrep_max_ws_rows
wsrep_max_ws_size
is nowcf_mysql.mysql.wsrep_max_ws_size
gcache_size
is nowcf_mysql.mysql.gcache_size
ib_log_file_size
is nowcf_mysql.mysql.ib_log_file_size
seeded_databases
is nowcf_mysql.mysql.seeded_databases
bootstrap_endpoint.username
is nowcf_mysql.mysql.bootstrap_endpoint.username
bootstrap_endpoint.password
is nowcf_mysql.mysql.bootstrap_endpoint.password
Proxy Job Spec Changes
- Move all properties to be under the top level
cf_mysql
key, except fornetwork_name
cluster_ips
now refers to the samecf_mysql.mysql.cluster_ips
from the mysql job spec- Rename the entire
proxy
hash tocf_mysql.proxy
- added
cf_mysql.proxy.arbitrator_ip
property 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
api_url
is nowcf.api_url
skip_ssl_validation
is nowcf.skip_ssl_validation
mysql_node.host
is nowcf_mysql.external_host
Move
auth_username
,auth_password
,cookie_secret
,max_user_connections_default
,services
,ssl_enabled
tocf_mysql: broker: auth_username: auth_password: cookie_secret: max_user_connections_default: services: ssl_enabled:
Rename
mysql_node
hash tocf_mysql.mysql
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
cf.apps_domain
is nowcf.app_domains
- Add
cf.smoke_tests.org
- Add
cf.smoke_tests.use_existing_org
smoke_tests_only
is nowcf_mysql.acceptance_tests.smoke_tests_only
standalone_tests_only
is nowcf_mysql.acceptance_tests.standalone_tests_only
timeout_scale
is nowcf_mysql.acceptance_tests.timeout_scale
- Move all
proxy
properties undercf_mysql.proxy
- Add
cf_mysql.broker.services
Bootstrap Errand Spec Changes
- All properties have been moved under
cf_mysql.mysql
Broker Registrar Errand Spec Changes
broker.host
is nowcf_mysql.external_host
- Remove
broker.name
broker.protocol
is nowcf_mysql.broker.brotocol
broker.services
is nowcf_mysql.broker.services
broker.username
is nowcf_mysql.broker.auth_username
broker.password
is nowcf_mysql.broker.auth_password
broker.protocol
is nowcf_mysql.broker.protocol
broker.port
is nowcf_mysql.broker.port
Broker Deregistrar Errand Spec Changes
broker.name
is removed- Added
cf_mysql.broker.services
Usage¶
You can reference this release in your deployment manifest from the releases
section:
- 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 upload-release
command:
bosh upload-release --sha1 43aa3449855a60b774c66cc5ab3f02caa43974dc \ "https://bosh.io/d/github.com/cloudfoundry/cf-mysql-release?v=26"
Jobs¶
- acceptance-tests
- arbitrator
- bootstrap
- broker-deregistrar
- broker-registrar
- cf-mysql-broker
- mysql
- proxy