Multi-AZ Deployment for MySQL

Tessell offers a highly available MySQL cluster solution designed for resilient and fault-tolerant Multi-AZ deployments using native Group Replication capabilities. Multi-AZ cluster consists of one primary DB instance and one or two readable failover replica instances (HA Replicas), distributed across different availability zones based on the customer's deployment preference. Tessell continuously replicates data from the primary DB instance to the failover replicas to ensure durability and availability.

Multi-AZ deployments use synchronous replication, which requires acknowledgment from at least one failover replica instance before a transaction can be committed on the primary. Failover replicas act as both automatic failover targets and read replicas, helping to improve application read throughput.

The following diagram shows 3-node Multi-AZ cluster:

Multi-AZ Deployment Types

Tessell supports two types of Multi-AZ cluster deployments: 2-node and 3-node MySQL HA clusters.

3-node Multi-AZ Cluster

A 3-node MySQL cluster provides a more robust and production-grade solution. It includes one primary and two failover read replicas distributed across three different availability zones within a region. This configuration allows quorum-based election during failovers, allowing the cluster to automatically promote a new primary as long as a majority (2 out of 3) nodes remain available. This design supports continued write operations during a single node or network failure, and handles split-brain scenarios gracefully with minimal impact on operations. Additionally, the two failover replica instances enhance read scalability and provide faster failover with reduced RTO. Although the infrastructure cost is higher, it delivers stronger resilience and uptime, making it ideal for mission-critical applications.

2-node Multi-AZ Cluster

A 2-node MySQL cluster offers a cost-efficient high availability configuration with one primary and one failover replica distributed across two different availability zones. It uses native group replication to maintain data consistency by requiring acknowledgment from HA replica before committing transactions on primary. However, during the event of network partitions, there is no quorum mechanism. As a result, write operations may be temporarily blocked to prevent data inconsistency. Tessell monitoring system detects such failures, transitions the primary node to standalone node to resume writes, and rejoins the failover replica once the network issue is resolved. While this design ensures data safety, it may increase recovery time (RTO). It is suitable for cost-sensitive environments with tolerance for longer recovery time.

Switchover in Multi-AZ Deployment

In a Multi-AZ deployment, if the primary database instance experiences either a planned or unplanned outage, the Tessell monitoring system automatically detects the failure and initiates a switchover to the High Availability (HA) replica that has the most up-to-date transaction state.

Switchover typically completes within 60 to 120 seconds. However, recovery time may be longer if the primary instance had large uncommitted or pending transactions that must be recovered and applied on the HA replica before it is promoted.

Automatic Switchovers

Tessell manages switchovers automatically to minimize downtime and eliminate the need for manual intervention.

When a failure is detected:

• The HA replica is promoted to primary.

• Traffic is redirected to the new primary instance.

• Database operations resume once promotion is complete.

This ensures business continuity with minimal disruption.

Manual Switchovers

Tessell also provides the option to manually trigger a switchover when required (for example, during maintenance or controlled testing). Manual switchover can be initiated using Tessell UI or API. This allows controlled switchover with predictable timing.

Steps to manually switch over in a Multi-AZ deployment

• Sign in to the Tessell Console.

• From the left navigation pane, go to DB Services and open the My Services App.

• Choose your MySQL DB service for which you want to fail over.

• Go to the Instances tab from the menu.

• Click on Switch over in the right panel menu.

• Choose the option Switchover to HA replica and tick the consent check box to proceed manual failover.

Limitations

• Multi-AZ deployment must be selected at the time of provisioning.

• Conversion from Single-AZ to Multi-AZ is not currently supported after the database has been provisioned.

• Conversion from Multi-AZ to Single-AZ is also not supported.

• Customers should carefully choose the deployment type (Single-AZ or Multi-AZ) based on their availability requirements during initial setup.

• Ensure that all tables have Primary key or equivalent unique key, and use Innodb storage engine.