LATEST VERSION: 2.5 - RELEASE NOTES

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 about PXC, see Percona XtraDB Cluster

    WARNING: Highly available (HA) cluster service plans are currently in beta. HA clusters are for advanced use cases only.

Pros and Cons

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

TopologyVMs neededProsCons
Single nodeone
  • 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-followertwo
  • 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 clusterthree and a jumpbox VM
  • Most expensive
  • Less flexible tuning than single node
  • Developers require moderate technical understanding
  • Apps cannot share the same data-set

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 three topologies.

RPOs

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

Type of downtimeSingle NodeLeader-FollowerHighly Available Cluster
Planned MaintenanceZero ZeroZero
Unplanned DowntimeZero Replica lag or 0 if in sync modeAlmost zero*
Data RecoveryTime since last backup Replica lag or 0 if in sync modeAlmost zero*

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

RTOs

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

Type of downtimeSingle NodeLeader-FollowerHighly Available Cluster
Planned MaintenanceTime required to restore the VM Time required depends on the type of maintenance Almost zero*
Unplanned DowntimeTime required to restore the VM Time required to restore the VM or time for operator to initiate failover and for failover to complete Almost zero*
Data RecoveryTime to restore from backup Time for operator to initiate failover and for failover to completeAlmost zero*

*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.

TopologyRisk-level
Single nodelow
Leader-followermedium
Highly available clusterhigh
Create a pull request or raise an issue on the source for this page in GitHub