Database outages — whether from instance failures, zone disruptions, or regional disasters — can cause data loss and extended downtime. ApsaraDB RDS provides a set of high availability (HA) features to address these risks: HA-optimized editions, dedicated instance types, multi-zone deployment, cross-region backup and restoration, and monitoring and alerting. Configure these features together to build a production-grade HA setup for your RDS instance.
Choose an edition and instance type
When you create an RDS instance, two options directly determine your baseline availability: Edition and Instance Type.
Edition
Select High-availability Edition or Cluster Edition. The following table summarizes what each edition provides.
| Edition | Architecture | Failover | Read scaling |
|---|---|---|---|
| High-availability Edition | Primary instance + secondary instance | Supported | Not supported on the secondary |
| Cluster Edition (MySQL) | One primary node + multiple secondary nodes; compute-storage separation | Automatic | Readable secondary nodes |
| Cluster Edition (SQL Server) | Primary instance + secondary instance + up to 7 read-only instances | Automatic | Read-only instances |
Cluster Edition for MySQL additionally supports:
MySQL Group Replication (MGR) mode, which delivers a Recovery Point Objective (RPO) of 0
Node addition and deletion, node-level monitoring, and cluster topology management
Multi-zone disaster recovery
Instance type
Select Dedicated or Dedicated Host to guarantee resource isolation.
| Instance type | Resource allocation |
|---|---|
| Dedicated | Exclusively occupies the CPU and memory allocated to it; performance is independent of other instances on the same physical host |
| Dedicated Host | Occupies all resources on the physical host |
Deployment zone
Select multi-zone deployment to get zone-level disaster recovery. If the primary instance's zone goes down, RDS automatically switches it to another zone. In single-zone deployments, you must wait for the fault to be resolved or manually fail over to a disaster recovery instance.
Configure automatic backup
Configure an automatic backup policy for your RDS instance. If the instance becomes unavailable due to misoperations or other exceptions, you can restore it to its latest state using these backups.
Set up cross-region disaster recovery
For protection against region-level outages, ApsaraDB RDS for MySQL provides two cross-region options:
Disaster recovery instance: Use Data Transmission Service (DTS) to synchronize data between your primary instance and a disaster recovery instance in real time. Both instances use the primary/secondary HA architecture. If a natural disaster takes out your primary and secondary instances, switch services to the disaster recovery instance and update the endpoints in your application.
Cross-region backup: Your database system automatically replicates backup files to an Object Storage Service (OSS) bucket in a different region. For configuration steps, see Use the cross-region backup feature.
Configure monitoring and alerting
Set thresholds on key performance metrics so you get alerted before CPU, disk, memory, or connection issues cause downtime. When a metric crosses its threshold, RDS generates an alert automatically. For configuration steps, see Configure alert rules for an ApsaraDB RDS for MySQL instance.
Recover from failures
With the architecture above in place, most faults are handled automatically. For active failures, use the following recovery paths:
| Failure scope | Recovery action |
|---|---|
| Single instance fault | Switch workloads between primary and secondary instances (not available in Basic Edition) |
| Zone fault (multi-zone deployment) | RDS automatically switches the primary instance to another zone |
| Zone fault (single-zone deployment) | Wait for the fault to be resolved, or switch services to the disaster recovery instance |
| Region fault | Switch services to the disaster recovery instance, or restore data from cross-region backup to a new RDS instance |
For detailed data restoration steps, see: