Warning: MySQL for Pivotal Platform v2.7x is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.
Page last updated:
This topic describes how the leader-follower topology works in MySQL for Pivotal Platform 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.
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 About Workload Types.
The following diagram shows a leader-follower service instance in two availability zones (AZs):
MySQL for Pivotal Platform 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, the follower is promoted to the leader and app traffic is sent to the follower.
For more information, see Triggering a Leader-Follower Failover.
By default, any data that is written to the leader is asynchronously replicated to the follower. MySQL for Pivotal Platform 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 information about enabling sync replication, see Synchronous Replication for Leader-Follower.
MySQL for Pivotal Platform automates orchestrating the standard lifecycle of creating, updating, and deleting leader-follower service instances.
In addition, MySQL for Pivotal Platform 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 configure-leader-follower in Running Errands.
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 availability zone (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.
For more information, see Availability Using Multiple AZs in MySQL for Pivotal Platform Recommended Usage and Limitations.
In addition to the standard networking rules needed for MySQL for Pivotal Platform, 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.