This topic describes how the leader-follower topology works in VMware Tanzu SQL with MySQL for VMs and contains information to help you decide whether to enable or use leader-follower.
Overview on Leader-Follower Topology
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 workload profiles. For more information, see About Workload Types.
The following diagram shows a leader-follower service instance in two availability zones (AZs):
.
In the previous diagram, the leader and follower nodes are each shown in their own AZ, separated by a dotted line.
An app sends traffic to the leader node. A two way arrow connects the leader to the follower indicating that any data that is written to the leader is replicated to the follower. The leader and the follower each have their own disk.
About failover
Tanzu SQL for VMs 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.
About synchronous replication
By default, any data that is written to the leader is asynchronously replicated to the follower. Tanzu SQL for VMs 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.
About leader-follower errands
Tanzu SQL for VMs automates orchestrating the standard lifecycle of creating, updating, and deleting leader-follower service instances.
In addition, Tanzu SQL for VMs 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.
Infrastructure Requirements for Leader-Follower Deployments
Leader-follower instances have additional infrastructure requirements to singleton instances, as described in the following section.
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 availability zone (AZ) outage and to remove single points of failure, VMware 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 VMware Tanzu SQL with MySQL for VMs Recommended Usage and Limitations.
Networking rules
In addition to the standard networking rules needed for Tanzu SQL for VMs, 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.
