Availability options

This topic tells you about the dessciptions and contrasts of the topologies for VMware SQL with MySQL for Tanzu Application Service and explains the kind of availability each provides.

VMware SQL with MySQL for Tanzu Application Service Topologies

The topologies offered by VMware Tanzu for MySQL 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 about how to provision a leader and follower VM, see About multi‑site replication.

Pros and cons

The following table 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	Simple Least expensive Straightforward operator experience Easy for the developer	No redundancy All data since last backup can be lost Data recovery requires restore from backup
Leader-follower	Two	Two copies of the data Data recovery is faster than single node	Less flexible tuning than single node Developers require some technical understanding Operator must initiate failover
Highly available cluster	Three and a jumpbox VM	Tightest RPO and RTO for downtime, including downtime for upgrades. See RPOs and RTOs.	Less flexible tuning than single node Developers require moderate technical understanding
Multi-Site Replication	Two	Two copies of the data Data recovery is faster than single node Resilience to data center outages and upgrades Developers can initiate failover	Less flexible tuning than single node Developers require some technical understanding
Highly available Multi-Site Leader	Six	Two copies of the data Data recovery is faster than single node Resilience to data center outages Resilience to upgrades Resilience to vm failures within a datacenter Developers can initiate failover	Most expensive Less flexible tuning than single node Developers require some technical understanding Increased network traffic

RPOs and RTOs

Recovery point objective (RPO) and recovery time objective (RTO) are important considerations for availability.

The following tables describe the RPOs and RTOs for the topologies.

RPOs

This table compares the recovery point objectives for the topologies:

Topology	Planned Maintenance	Unplanned Downtime	Data Recovery
Single Node	Zero	Zero	Time since last backup
Leader-Follower	Zero	Replica lag, or zero if in sync mode	The time to initialize the follower VM, or zero if in sync mode
Highly Available Cluster	Zero	Almost zero*	Almost zero*
multi‑site replication	Zero	Replica lag	Replica lag
Highly Available Multi-Site Leader	Zero	Almost zero*	Almost zero*

*Database clients are notified that incomplete transactions are not saved.

RTOs

This table compares the recovery time objectives for the topologies:

Topology	Planned Maintenance	Unplanned Downtime	Data Recovery
Single Node	Time required to recreate the VM and reconnect to storage	Time required to recreate the VM and reconnect to storage	Time to restore from backup
Leader-Follower	Time required depends on the type of maintenance	Time required to restore the VM or time for operator to initiate failover and for failover to complete	Time for operator to initiate failover and for failover to complete
Highly Available Cluster	Almost zero*	Almost zero*	Almost zero*
multi‑site replication	Time for developer to initiate switchover and for switchover to complete	Time for developer to initiate failover and for failover to complete	Time for developer to initiate failover and for failover to complete
Highly Available Multi-Site Leader	Almost zero*	Almost zero*	Almost zero*

*This includes time for apps to reconnect to the MySQL service instance.

Risk

When you choose a topology, risk is a factor to consider. Risk 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
Highly Available Multi-Site Leader	High