Availability Options

Page last updated:

This topic describes and contrasts the three topologies for MySQL and explains the kind of availability each provides.

Three Topologies

The three topologies offered in MySQL for PCF v2.5 are as follows:

Single node—This simple one-VM topology is inexpensive and good for testing and for apps where high availability is not important.
Leader-follower—This two-VM topology gives you redundancy through failover of the leader to the follower. 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 three topologies. For more information, see About Highly Available Clusters.

Warning: Highly available plans are currently in beta. HA clusters are for advanced use cases only.

The table below lists some key characteristics of the three topologies to help you decide which one is best for your developers.

Topology	VMs needed	Pros	Cons
Single node	one	Simple Least expensive Apps can share the same data-set 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 Apps can share the same data-set 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. See RPOs and RTOs below.	Most expensive Less flexible tuning than single node Developers require moderate technical understanding Apps cannot share the same data-set

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

The tables below describe the RPOs and RTOs for the three topologies.

This table compares the recovery point objectives for the three topology types.

Type of downtime	Single Node	Leader-Follower	Highly Available Cluster
Planned Maintenance	Zero	Zero	Zero
Unplanned Downtime	Zero	Replica lag or 0 if in sync mode	Almost zero*
Data Recovery	Time since last backup	The time to initialize the follower VM or 0 if in sync mode	Almost zero*

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

This table compares the recovery time objectives for the three topology types.

Type of downtime	Single Node	Leader-Follower	Highly Available Cluster
Planned Maintenance	Time required to recreate the VM and reconnect to storage	Time required depends on the type of maintenance	Almost zero*
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*
Data Recovery	Time to restore from backup	Time for operator to initiate failover and for failover to complete	Almost zero*

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

When choosing a topology, risk is a factor to consider. Risk, in this case, encompasses the likelihood of:

Single node topology has the lowest risk. Highly available clusters have the highest risk.