Recommended use cases
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.
About on-demand plans
- 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.
- Operators can update the plan settings, including the VM size and disk size after the plans have been created. Operators cannot 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.
Resource usage planning for on-demand plans
For information on setting limits and calculating costs for on-demand service instances, see Setting limits for on-demand service instances.
Availability using multiple AZs
VMware SQL with MySQL for Tanzu Application Service supports configuring multiple availability zones (AZs). However, assigning multiple AZs to MySQL jobs does not guarantee high availability.
- You can assign on-demand plans to any of the configured AZs.
- BOSH randomly deploys service instances across configured AZs. This minimizes the impact of an AZ outage and removes single points of failure.
- For all VMware Tanzu for MySQL plans, select three AZs. Choosing three AZs does not increase the number of AZs assigned to service instances to three.
Downtime during redeploys
By default, VMware Tanzu for MySQL does a rolling deploy during upgrades or when you apply configuration changes. For single node and leader-follower plans, this results in VMware Tanzu for MySQL being inaccessible to apps for a brief period of time.
If you are using a HA cluster plan, VMware Tanzu for MySQL uses rolling redeploys and your service does not incur downtime. You can mitigate downtime by using HA cluster plans.
For more information about downtime in VMware Tanzu for MySQL, see RPOs and RTOs.
Persistent disk usage
Persistent disks store your application data, InnoDB redo logs and binlogs. If your app is write-heavy, increase your persistent disk to accommodate the binlogs. InnoDB redo logs use a static amount of disk size. HA cluster jumpboxes require persistent disk sufficient to hold backup artifacts during certain database restore operations.
For the amount of persistent disk required for your service plan, see the following sections:
In the following discussion, N represents your expected application data volume in gigabytes.
Single node and leader-follower
You can configure the persistent disk size for single node or leader-follower VMs. For instructions for configuring disk size, see Configure service plans.
Use the following table to determine the amount of persistent disk space you need:
| InnoDB Redo Logs | Total Disk Size | Minimum Total Disk Size |
|---|---|---|
| 512 MB | N GB + 512 MB | 3 GB |
The following diagram shows how persistent disk space is used:
Multi-Site Replication
You can configure the persistent disk size for Multi-Site Replication VMs. For instructions for configuring disk size, see Configure service plans.
Use the following table to determine the amount of persistent disk space you need:
| InnoDB Redo Logs | Total Disk Size | Minimum Total Disk Size |
|---|---|---|
| 2 GB | N GB + 2 GB | 5 GB |
The following diagram shows how persistent disk space is used:
HA Cluster Jumpbox
You can configure the persistent disk size for HA cluster jumpbox VMs. For instructions for configuring disk size, see Configure service plans.
Use the following table to determine the amount of persistent disk space you need:
| InnoDB Redo Logs | Total Disk Size | Minimum Total Disk Size |
|---|---|---|
| 2 GB | N GB + 2 GB | 5 GB |
The following diagram shows how persistent disk space is used:
HA cluster node
You can configure the persistent disk size for HA cluster node VMs. For instructions for configuring disk size, see Configure service plans.
Use the following table to determine the amount of persistent disk space you need:
| InnoDB Redo Logs | Total Disk Size | Minimum Total Disk Size |
|---|---|---|
| 2 GB | N GB + 2 GB | 5 GB |
You must include binlogs in your size estimate for app data.
The following diagram shows how persistent disk space is used:
