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 Tanzu SQL with MySQL for VMs 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 Tanzu SQL for VMs 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, Tanzu SQL for VMs does a rolling deploy during upgrades or when you apply configuration changes. For single node and leader-follower plans, this results in Tanzu SQL for VMs being inaccessible to apps for a brief period of time.
If you are using a HA cluster plan, Tanzu SQL for VMs 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 Tanzu SQL for VMs, see RPOs and RTOs.
Persistent disk usage
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.
For the amount of persistent disk required for your service plan, see the following sections:
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 | 3N + 512MB | 5 GB |
In the Total Disk Size formula from the previous table, N represents the following items in equal value:
- Maximum app data. Remember to include binlogs in your size estimate for app data.
- Data for copied backups.
- Data for compression and encryption.
Each N combined makes 3N, as seen in the formula.
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 | 3N + 2 GB | 5 GB |
In the Total Disk Size formula from the previous table, N represents the following items in equal value:
- Maximum app data. Remember to include binlogs in your size estimate for app data.
- Data for copied backups.
- Data for compression and encryption.
Each N combined makes 3N, as seen in the formula.
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 | 2N + 2 GB | 10 GB |
In the Total Disk Size formula from the previous table, N represents the following items in equal value:
- Data for copied backups.
- Data for compression and encryption.
Each N combined makes 2N, as seen in the formula.
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 + 2 GB | 5 GB |
In the Total Disk Size formula from the previous table, N represents maximum app data. You must include binlogs in your size estimate for app data.
The following diagram shows how persistent disk space is used:
