Availability Options
Warning: MySQL for VMware Tanzu v2.8 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.
Page last updated:
This topic describes and contrasts the topologies for MySQL for VMware Tanzu and explains the kind of availability each provides.
MySQL for VMware Tanzu Topologies
The topologies offered by MySQL for VMware Tanzu are:
Single node: This one-VM topology is inexpensive and good for testing. You can use this topology for apps where high availability is not important.
Leader-follower: This two-VM topology gives you redundancy through failover of the leader VM to the follower VM. For more information, see About Leader-Follower.
Highly available (HA) cluster: This three-VM plus jumpbox cluster uses a patched Galera cluster, Percona XtraDB Cluster (PXC), to provide the greatest availability of the topologies. For more information, see About Highly Available Clusters.
Multi‑Site Replication: This two-VM topology enables you to provision a leader and follower VM in two different foundations. For more information, see About Multi‑Site Replication.
Pros and Cons
The table below lists some key characteristics of the topologies to help you decide which one is best for your developers.
| Topology | VMs needed | Pros | Cons |
|---|---|---|---|
| Single node | One |
|
|
| Leader-follower | Two |
|
|
| Highly available cluster | Three and a jumpbox VM |
|
|
| Multi‑Site Replication | Two |
|
|
RPOs and RTOs
Recovery point objective (RPO) and recovery time objective (RTO) are important considerations for availability.
The tables below describe the RPOs and RTOs for the topologies.
RPOs
This table compares the recovery point objectives for the topologies.
| Type of downtime | Single Node | Leader-Follower | Highly Available Cluster | Multi‑Site Replication |
|---|---|---|---|---|
| Planned Maintenance | Zero | Zero | Zero | Zero |
| Unplanned Downtime | Zero | Replica lag, or zero if in sync mode | Almost zero* | Replica lag |
| Data Recovery | Time since last backup | The time to initialize the follower VM, or zero if in sync mode | Almost zero* | Replica lag |
*Database clients are notified that incomplete transactions are not saved.
RTOs
This table compares the recovery time objectives for the topologies.
| Type of downtime | Single Node | Leader-Follower | Highly Available Cluster | Multi‑Site Replication |
|---|---|---|---|---|
| Planned Maintenance | Time required to recreate the VM and reconnect to storage | Time required depends on the type of maintenance | Almost zero* | Time for developer to initiate switchover and for switchover to complete |
| Unplanned Downtime | Time required to recreate the VM and reconnect to storage | Time required to restore the VM or time for operator to initiate failover and for failover to complete | Almost zero* | Time for developer to initiate failover and for failover to complete |
| Data Recovery | Time to restore from backup | Time for operator to initiate failover and for failover to complete | Almost zero* | Time for developer to initiate failover and for failover to complete |
*This includes time for apps to reconnect to the MySQL service instance.
Risk
When choosing a topology, risk is a factor to consider. Risk, in this case, encompasses the likelihood of:
Operators being interrupted to perform disaster recovery
Encountering issues because of the complexity of the topology and technology
Single node topology has the lowest risk. Highly available clusters have the highest risk.
| Topology | Risk-level |
|---|---|
| Single node | Low |
| Leader-follower | Medium |
| Highly available cluster | High |
| Multi‑Site Replication | Medium-high |