ApsaraDB RDS protects your data through multiple layers of redundancy: automatic backups for point-in-time recovery, zone-level redundancy to survive availability zone failures, and cross-region backup for broader disaster recovery needs. The right combination depends on your edition and recovery objectives.
Edition overview
The three RDS editions differ in their high availability (HA) architecture:
| Edition | Architecture | Multi-zone support | Read scale-out |
|---|---|---|---|
| RDS Basic Edition | Single primary instance, no hot standby | No | No |
| RDS High-availability Edition | Primary + secondary instance (active-active) | Yes (no extra charge) | No |
| RDS Cluster Edition | Primary node + multiple secondary nodes | Yes | Yes — secondary nodes handle read requests |
Data backup and restoration
ApsaraDB RDS enables automatic and manual backups by default. Set a backup schedule that matches your recovery objectives, or trigger a manual backup at any time.
Backup file restoration and point-in-time recovery: ApsaraDB RDS allows you to restore data from backup files or restore data to a specific point in time. In most cases, you can restore to any point within the last seven days to a temporary or cloned RDS instance. After verifying the data, migrate it back to the primary instance to complete the rollback. For details, see Backup and restoration.
Cross-region backup: Store backups in a different region for broader disaster recovery coverage. For details, see Use the cross-region backup feature and Restore data across regions.
Zone-disaster recovery
RDS Basic Edition
RDS Basic Edition runs on a single primary instance with no secondary instance for hot standby. Backups are stored in Object Storage Service (OSS) buckets or distributed cloud disks, using multi-replica redundancy to ensure data reliability. This backup mechanism applies to all RDS instances regardless of edition.
Because there is no secondary instance, recovery from an instance failure takes longer. This edition is suitable for scenarios that do not require high availability.
RDS High-availability Edition
RDS High-availability Edition runs a primary and a secondary instance in active-active mode. When the primary instance fails, workloads switch to the secondary instance within seconds, transparently to your application. If the secondary instance fails, ApsaraDB RDS automatically provisions a replacement to restore HA.
This edition covers more than 80% of production scenarios.
Single-zone deployment: The primary and secondary instances run in the same zone on separate physical servers. The zone provides redundant racks, heating, ventilation, and air conditioning (HVAC) systems, circuits, and networks.
Multi-zone deployment: The primary and secondary instances run in different zones within the same region, also called a local dual-data center or local disaster recovery configuration. Cross-zone disaster recovery is included at no extra charge.
Single-zone and multi-zone instances can be converted at any time:
-
Migrate an ApsaraDB RDS for PostgreSQL instance across zones
-
Migrate an ApsaraDB RDS for SQL Server instance across zones
RDS Cluster Edition
RDS Cluster Edition adds read scale-out on top of HA. One primary node handles writes while multiple secondary nodes serve read requests, eliminating the need to purchase separate read-only clusters. Multi-zone deployment is supported.
ApsaraDB RDS for MySQL
RDS Cluster Edition for MySQL supports MySQL 5.7 and MySQL 8.0. An instance running this edition is called an RDS cluster. For details, see RDS Cluster Edition.
Secondary nodes are accessible through the read-only endpoint of the RDS cluster. During a failover, ApsaraDB RDS automatically:
-
Promotes a secondary node to primary, removes it from the read-only endpoint, and closes its read connections. Transient connections occur on the read-only endpoint during this step.
-
Removes the faulty primary node from the read/write endpoint, then adds the promoted node to the read/write endpoint.
-
After the original primary node recovers, adds it to the read-only endpoint with the read weight inherited from the promoted secondary node.
Read-only endpoint availability during failover:
-
One secondary node: The read-only endpoint is unavailable until the original primary node recovers.
-
Multiple secondary nodes: A transient connection occurs, but the remaining secondary nodes continue to handle read requests.
Configure multiple secondary nodes to maintain read-only endpoint access during failovers.
ApsaraDB RDS for SQL Server
RDS Cluster Edition for SQL Server consists of a primary instance and a secondary instance with the same high availability as RDS High-availability Edition. Create up to seven read-only instances for the primary instance to scale out read capacity. All read-only instances and the secondary instance replicate data from the primary instance. Read-only nodes can be deployed in zones other than those of the primary and secondary nodes. For details, see Overview of read-only ApsaraDB RDS for SQL Server instances.