Multi-AZ Deployment Overview
Download
Mode fokus
Ukuran font
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
Attention:
To prevent misuse, the TDSQL Boundless console no longer provides the primary AZ configuration and does not recommend that users use it.
Note:
When you change the source AZ, second-level connection interruptions may occur. Ensure that your business side has a reconnection capability.
For a multi-AZ instance, you can set a source AZ. After you set it, the node weight in that AZ is increased to 99%, and approximately 99% of requests are prioritized for processing in that AZ.
After you set a source AZ, the instance configuration cannot be adjusted. If you need to change the configuration, temporarily cancel the source AZ configuration first. This allows TDSQL Boundless to switch the Leader as needed during the configuration change to ensure business continuity. Before performing this operation, evaluate the potential performance impact of canceling the source AZ.
To prevent misuse, the primary AZ configuration is no longer available in the TDSQL Boundless console. Existing customers for whom this feature has been enabled can continue to use it through the allowlist feature. New customers who need to enable it should contact Tencent Cloud Technical Support.
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.
Full-featured Replica quantity is 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.
Full-featured replica quantity is 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.
Bantuan dan Dukungan
Apakah halaman ini membantu?
Anda juga dapat Menghubungi Penjualan atau Mengirimkan Tiket untuk meminta bantuan.
masukan