Warning: MySQL for Pivotal Platform v2.4 is no longer supported because it has reached the End of General Support (EOGS) phase. To stay up to date with the latest software and security updates, upgrade to a supported version.
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.
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.
By default, any data that is written to the leader is asynchronously replicated to the follower. MySQL for PCF also supports synchronous replication (“sync”).
In sync replication, data does not get committed to the leader node until the follower acknowledges the commit and can replicate it. By default, the timeout for sync replication is set to approximately 292 million years. This means that the leader always waits for the follower to confirm receipt of the transaction.
For more information about sync replication, see Understanding Synchronous Replication.
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 configure
For more 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.
The following diagram shows a leader-follower service instance in two availability zones (AZs):
Leader-follower instances have additional infrastructure requirements to singleton instances, as described below.
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.
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.
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.
For information on enabling and using leader-follower, see Using Leader-Follower Topology For Availability.
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.
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.