MySQL for Pivotal Platform Recommended Usage and Limitations
Page last updated:
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 200.
- 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 Pivotal Platform 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. If you plan to configure highly available clusters, Pivotal recommends three availability zones as described in the About Highly Available Clusters page.
Redeploying MySQL for Pivotal Platform for configuration changes or upgrades will result in MySQL being inaccessible to apps for a brief period of time.
The persistent disk receives, temporarily stores and encrypts MySQL backups. This results in increased disk usage while backups are being processed. For single node and leader-follower service plans, backups are processed on the MySQL VM. For highly available (HA) clusters, backups are processed on the jumpbox VM.
In addition to backups, the persistent disk also stores InnoDB redo logs and binlogs. InnoDB redo logs use a static amount of disk size. If your app is write-heavy, increase your persistent disk to accommodate the binlogs.
Use the following table to determine the amount of persistent disk space you need to set when you configure a service plan. For instructions for configuring service plans, see Configure Service Plans.
|Persistent Disk||Modifier for Copied Backups, Compression, and Encryption||InnoDB Redo Logs||Total Disk Size*|
|Single Node||3||512 MB||3N + 512 MB|
|Leader-Follower||3||512 MB||3N + 512 MB|
|HA Cluster Jumpbox||2||2 GB||2N + 2 GB|
|HA Cluster Node||n/a||2 GB||N + 2 GB|
Nis the maximum amount of app data that a developer needs. Remember to include binlogs in your size estimate for app data.
The following diagram shows how persistent disk space is used in the single node and leader-follower topologies and in the HA cluster topology: