LATEST VERSION: 2.3 - RELEASE NOTES

About Leader-Follower

This topic describes how the leader-follower topology works in MySQL for Pivotal Cloud Foundry (PCF) and contains information to help users decide whether to enable or use leader-follower.

Understanding Leader-Follower

The leader-follower topology increases the availability of a MySQL database by deploying two MySQL VMs in two separate availability zones (AZs). When a developer creates a leader-follower service instance, the on-demand broker deploys a leader VM in one AZ, and a follower VM in another AZ. Any data that is written to the leader is asynchronously replicated to the follower.

A leader-follower topology enables operators to initiate a failover and send app traffic to the follower if the leader fails. This ensures that the app bound to the MySQL database continues to function normally.

The follower VM is only for increasing availability and is not exposed to developers to increase read throughput. Developers who want increased read throughput can do this by configuring workload profiles. For information, see Understanding Workload Types.

For high-level information on the leader-follower process, see Leader-Follower Setup and Failover Process.

Note: The term leader-follower is analogous to master-slave.

Infrastructure Requirements for Leader-Follower Deployments

Leader-follower instances have additional infrastructure requirements to singleton instances, as described below.

Capacity Planning

When calculating IaaS usage, you must take into account that each leader-follower instance requires two VMs. Therefore, the resources used for a leader-follower-enabled plan must be doubled. For more information, see Resource Usage Planning for On-Demand Plans.

Availability Zones

To minimize impact of an AZ outage and to remove single points of failure, Pivotal recommends that you provision three AZs if using leader-follower deployments. With three AZs, the MySQL VMs are deployed to two AZs, and the broker is deployed to a third.

Networking Rules

In addition to the standard networking rules needed for MySQL for PCF, the operator must ensure leader-follower-specific network rules are also set up as follows:

  • Leader-follower VMs bidirectionally communicate with each other over port 8008 for orchestration.
  • Leader-follower VMs bidirectionally communicate with each other over port 3306 for replication.

For information about the standard networking rules, see Required Networking Rules for On-Demand Services.

Enabling and Using Leader-Follower

For information on enabling and using leader-follower, see Using Leader-Follower Topology For Availability.

Understanding Failover

MySQL for PCF focuses on data consistency rather than availability. Therefore, it does not trigger failover automatically, but relies on operators to trigger a failover. When an operator triggers a failover, app traffic is sent to the follower.

For more information, see Trigger a Failover.

Understanding Leader-Follower Errands

MySQL for PCF automates orchestrating the standard lifecycle of creating, updating, and deleting leader-follower service instances.

In addition, MySQL for PCF provides three leader-follower errands. An operator can use them to control the lifecycle of a leader-follower service instance and manually intervene, when necessary, without being an expert at MySQL.

For more information, see Leader-Follower Errands.

Create a pull request or raise an issue on the source for this page in GitHub