MySQL for PCF Recommended Usage and Limitations
MySQL is a powerful open-source relational database used by apps since the mid-90s. Developers have relied on MySQL as a first step to storing, processing and sharing data. As its user community has grown, MySQL has become a robust system capable of handling a wide variety of use cases and very significant workloads. Unlike other traditional databases which centralize and consolidate data, MySQL lends itself to dedicated deployment supporting the “shared nothing” context of building apps in the cloud.
- Each on-demand plan instance is deployed to its own VM and is suitable for production workloads.
- The maximum-number of on-demand plan instances available to developers is set by the operator and enforced on both a global and per-plan level quota. The global quota cannot exceed 50.
- Operators can update the plan settings, including the VM size and disk size after the plans have been created. Operators should not downsize the VMs or disk size as this can cause data loss in pre-existing instances.
- All plans deploy a single VM of the specified size with the specified disk type.
- Cannot scale down the size of VMs on the plan once deployed (this protects against data loss).
- The default maximum number of connections is set at 750.
For information on setting limits and calculating costs for on-demand service instances, see Setting Limits for On-Demand Service Instances.
MySQL for PCF v2 supports configuring multiple availability zones. At a minimum, Pivotal recommends using two availability zones, one for the broker and one for the MySQL VMs. If you plan to configure leader follower, Pivotal recommends three availability zones as described in the About Leader-Follower page.
Redeploying MySQL for PCF for configuration changes or upgrades will result in MySQL being inaccessible to apps for a brief period of time.
MySQL backups are taken on the VM and temporarily stored and encrypted on the VM. This results in increased disk usage while backups are being taken. When enabling backups, we recommend choosing persistent disk sizes that are three times larger than you intend to be available to app developers using the service.
Backups require two to three times as much disk space as the server needs. The first is for the actual data, the second is the copied backup, and the third is for the encrypted backup.