TDSQL Boundless instances support multi-AZ deployment. Compared to single-AZ deployment, the multi-AZ deployment approach offers higher disaster recovery capabilities. It protects the database against instance failures or AZ outages, enabling resilience to data center-level failures. Multi-AZ deployment provides high availability and failover support for database instances. A multi-AZ is a physical region formed by combining multiple single AZs within the same geographic area at the single-AZ level. This document introduces the basic concepts, deployment methods, core concepts, and applicable scenarios of TDSQL Boundless multi-AZ deployment.
Note:
In multi-AZ deployment mode, strong synchronous replication is employed between AZs to ensure strong data consistency.
Prerequisites
The region where the instance is located must contain multiple AZs.
Sufficient resources must be available in the target AZ.
Fee Instructions
No additional fees are charged for the multi-AZ deployment feature.
Instances currently deployed in a single AZ can be upgraded to multi-AZ deployment free of charge.
Note:
Deployed instances can be reconfigured online based on business changes. For details, see Adjust AZs. Core Concepts
Replica Types
Full-featured Data Replica: This is the most widely used replica type. It stores all complete data and features, including full data and transaction logs, and can be quickly switched to the Leader at any time to provide external read and write services.
Log Replica: This is a lightweight replica that only stores transaction logs and participates in Raft voting. It does not host user data or provide read/write services. Its sole purpose is to achieve a majority in scenarios such as dual-AZ deployments to ensure cross-AZ high availability.
Primary AZ
For multi-AZ instances, you can designate a primary AZ. After this configuration, approximately 99% of requests are routed to and processed in that AZ by default, significantly reducing cross-AZ access latency between the application and the database.
Deployment Architecture
TDSQL Boundless provides the following three deployment methods. You can select the appropriate solution based on your business's availability requirements and performance needs.
Three-AZ Deployment: Instances are deployed with three full-featured replicas by default. The number of nodes in an instance is evenly distributed across the three AZs.
Dual-AZ Deployment: Instances are deployed with two full-featured replicas + one log replica by default. The number of nodes in an instance is evenly distributed across the two AZs.
Single-AZ Deployment: Instances can be deployed with either three full-featured replicas or two full-featured replicas + one log replica.
Three-AZ Deployment
Note:
When deployment across three AZs is performed, the number of peer nodes in an instance must be an integer multiple of 3.
Three-AZ deployment provides you with a highly available solution that stably supports multi-AZ disaster recovery. The peer nodes of an instance are evenly distributed across three AZs, and data replicas are synchronized across three AZs. This solution offers automatic AZ failover capability and is suitable for core business scenarios or businesses with high availability requirements and sufficient budgets.
Under normal circumstances, read/write traffic can be evenly distributed across the three AZs.
If any one AZ fails, the remaining two AZs can still form a majority. The system automatically performs the failover, and services are restored without manual intervention.
Dual-AZ Deployment
Note:
When deployment is performed across two AZs, the number of peer nodes in an instance must be an integer multiple of 2. Log replicas that only vote are not charged.
Dual-AZ deployment provides you with a balanced solution between cost and cross-AZ disaster recovery. The peer nodes of an instance are evenly distributed across two AZs, with each AZ holding a full-featured data replica. Additionally, a log replica is deployed in the system's arbitration AZ. This log replica only participates in voting and does not store data, ensuring that a majority vote can still be automatically completed if any AZ fails. This solution is suitable for cost-sensitive businesses with clear requirements for cost reduction.
Under normal circumstances, read/write traffic can be evenly distributed across the two AZs.
If any one AZ fails, the remaining one full-featured data replica and the log replica can still form a majority. The system automatically performs the failover, and services are restored without manual intervention.
Single-AZ Deployment
Warning:
In a single-AZ deployment, all nodes of an instance are deployed within the same AZ. If that AZ fails, service becomes unavailable. This deployment model is suitable for development and testing, cost-sensitive businesses, or scenarios that do not have strong requirements for cross-AZ disaster recovery.
Note:
In a single-AZ deployment, the number of peer nodes in an instance must be an integer multiple of the number of full-featured replicas.
In a single-AZ deployment, all peer nodes of an instance are deployed within the same AZ. Node-level high availability is ensured through Raft multi-replica replication. This approach has the lowest resource cost but cannot handle AZ-level failures. It supports two replica configurations and is suitable for development and testing, cost-sensitive businesses, or scenarios that do not have strong requirements for cross-AZ disaster recovery.
Number of Full-Featured Replicas: 3: Instances are deployed with three full-featured replicas. The number of nodes in an instance must be an integer multiple of 3, and data is evenly distributed across the nodes.
Number of Full-Featured Replicas: 2: Instances are deployed with two full-featured replicas + one log replica. The number of nodes in an instance must be an integer multiple of 2, and data is evenly distributed across the nodes.