TDSQL-C for MySQL allows you to select a primary AZ and a secondary AZ when a cluster is created. If you choose the single-AZ deployment mode during cluster creation, you can also configure it for multi-AZ deployment after creation. This document describes how to set up multi-AZ deployment through the purchase page and the console.
Multi-AZ Deployment Scenarios and Advantages
TDSQL-C for MySQL supports deployment across multiple AZs within the same region. Compared to single-AZ deployment, the multi-AZ deployment mode offers higher availability and disaster recovery capabilities.
Multi-AZ deployment provides enhanced availability and durability for TDSQL-C for MySQL clusters. When you provision a multi-AZ database cluster, TDSQL-C for MySQL automatically creates a primary database instance and synchronously replicates data to a standby instance in another AZ. Each AZ operates on its own independent, physically distinct infrastructure, which is designed for high reliability. If an infrastructure failure occurs, an automatic failover to the standby instance is performed, enabling you to resume database operations immediately after the failover completes. Because the endpoint for the database instance remains unchanged after failover, your applications can resume database operations without requiring manual administrative intervention.
Billing Overview
Billing Effective Time and Scope
The billing rules for Multi-AZ deployment take effect from 00:00:00 on October 12, 2026. These rules apply to the billing for Multi-AZ deployment of TDSQL-C for MySQL clusters.
Multi-AZ Billing Scope and Billing Ratio
|
Computing Resource | Multi-AZ CPU, multi-AZ memory, multi-AZ CCU | Primary and secondary instances are billed at a 1:1 ratio. |
Storage Resource | Multi-AZ storage | Primary and secondary instances are billed at a 1:0.45 ratio. |
When a cluster is configured for Multi-AZ deployment, the node quantity and specification configuration of the secondary instance (the node in the cluster's secondary AZ) remain consistent with those of the primary instance.
The secondary instance does not support read/write operations and is used solely for disaster recovery.
After you enable Multi-AZ deployment, the compute cost for the cluster will be doubled, and the storage cost will increase by 45%. For the specific costs of compute and storage resources, see Product Pricing. binlog Replication Mode
After you configure a cluster for Multi-AZ deployment, you can set the binlog replication mode through the console. Setting the binlog replication mode involves configuring the transmission mechanism and consistency level for data synchronization between the primary database instance and the standby instance. The binlog replication modes supported by TDSQL-C for MySQL and their brief descriptions are listed below. For detailed information, see the Multi-AZ Deployment Overview. Asynchronous Replication: The primary database instance returns success immediately after committing a transaction and writing to the binlog, without waiting for the standby instance to receive the data. This replication mode offers high performance, but a primary database failure has a small probability of causing data inconsistency.
Semi-synchronous Replication: After the primary database instance commits a transaction, it must wait for the standby instance to receive the binlog and write it to the relay log (application completion is not required) before returning success. This replication mode balances performance and consistency, avoiding the data loss risk inherent in purely asynchronous replication, but introduces a small amount of additional latency. If an exception occurs during data replication, the primary database instance pauses its response to the application (for about 10 seconds by default) and downgrades the replication mode to asynchronous replication. When data replication returns to normal, the replication mode is restored to semi-synchronous replication.
Strong Synchronous Replication: The primary database instance must wait for the standby instance to apply the binlog before returning success, ensuring strict data consistency between the primary and standby instances. This replication mode offers high data security but incurs relatively significant performance degradation. If an exception occurs during data replication, the replication mode is not downgraded. To ensure data consistency, the primary database instance pauses its response to the application until the exception ends.
Setting Multi-AZ Deployment on the Purchase Page When a Cluster is Created
2. On the purchase page, under the Database Configuration option, select the target region. The configurable primary AZ and secondary AZs will then be displayed below for you to select as needed.
3. After the database configuration is selected, click Next to go to the Basic Info and Advanced Configuration options.
4. After completing the setup and confirming that everything is correct, click Buy Now.
5. After the purchase is completed, you can view the AZ information in the corresponding view.
After the purchase is completed, return to the cluster list. Once the status of the newly created cluster changes to Running, you can view the AZ information in the topology diagram under Cluster Details on the cluster management page.
After the purchase is completed, return to the cluster list. Once the status of the newly created cluster changes to Running, you can query the AZs either from the cluster list page or by clicking the cluster ID to go to the Availability Info section on the Cluster Details page.
Setting Multi-AZ Deployment via the Console After Cluster Creation (Prerequisite: Single-AZ Deployment at Creation)
1. On the cluster list page, perform operations based on the view mode you are using to go to the Modify Deployment Mode page.
1. Log in to the TDSQL-C for MySQL console and click the target cluster in the cluster list on the left to go to the Cluster Management page. 2. On the cluster management page, click the edit icon next to Deployment Mode.
1. Log in to the TDSQL-C for MySQL console. In the cluster list, click the cluster ID or Manage in the Operation column to go to the cluster details page. 2. On the cluster details page, in the Availability Info module, click Modify next to Deployment Mode to modify the AZs.
2. Complete the following configurations in the pop-up dialog box and click OK.
Note:
Currently, only secondary AZs can be modified. Primary AZs cannot be modified at this time.
|
Multi-AZ Deployment | Select Yes to change the cluster from a single AZ to a multi-AZ deployment. |
Replica AZ | Select the AZ for the standby database. The AZs supported for selection in a specific region are subject to the actual Modify Deployment Mode window. |
Binlog Replication Method | Select the binlog replication mode. The default is Async replication. Async replication, Semi-sync replication, and Strong sync replication are supported. |
Note:
If you select strong synchronous replication as the binlog replication mode, note that it may impact instance performance.
Related APIs
|
| This interface (AddClusterSlaveZone) is used to enable Multi-AZ deployment for a cluster. |
| This API (DescribeSlaveZones) is used to query the secondary AZs of a cluster. |