ApsaraDB for RDS provides a complete suite of high availability features such as the dedicated instance family, high availability-centered RDS editions, multi-zone deployment, and cross-region backup and restoration.
RDS editions and instance families
When you create an RDS instance, note the following high availability-related options:
- Edition: We recommend that you select the High-availability, Enterprise, or Cluster (AlwaysOn) Edition.
- High-availability: The database system works in the classic high-availability architecture and consists of one primary instance and one secondary instance.
- Enterprise: The database system consists of one primary instance and two secondary instances. The primary and secondary instances reside in three different zones within the same region to provide financial-level reliability.
- Cluster (AlwaysOn): This edition is only supported for SQL Server. The database system consists of one primary instance, one secondary instance, and up to seven read-only instances used to scale out the read capability.
- Zone: ApsaraDB for RDS supports both single-zone deployment and multi-zone deployment. We recommend that you use multi-zone deployment. If your database system spans multiple zones, it can provide zone-level disaster recovery.
- Instance Type: We recommend that you select the Dedicated Instance or Dedicated Host family.
- Dedicated Instance: A dedicated instance occupies the exclusive CPU and memory resources allocated to it. Its performance and stability are independent of the other instances deployed on the same physical host.
- Dedicated Host: This is the top configuration of the Dedicated Instance family. A dedicated host instance occupies all resources on the physical host where it is housed.
We recommend that you configure an automatic backup policy for your ApsaraDB for RDS instance. If your instance becomes unavailable due to misoperations or other exceptions, you can use the backups to restore the instance to its latest state.
Cross-region disaster recovery
The cross-region disaster recovery feature helps secure your data and increases the availability of your RDS instances.
- Create a disaster recovery ApsaraDB RDS for MySQL instance: The primary instance and its remote disaster recovery instance synchronize data with each other in real time by using Data Transmission Service (DTS). Both the primary and disaster recovery instances are deployed based on the primary/secondary high availability architecture. If your application cannot connect to either the primary or secondary instance due to a natural disaster, you can switch services over to the remote disaster recovery instance and then update the endpoints on your application. This minimizes the downtime of your database system.
- Back up an ApsaraDB RDS for MySQL instance across regions: Your database system automatically replicates its backup files to OSS buckets in a different region.
Monitoring and alerting
To prevent unavailability caused by CPU, disk, memory, connection, or other exceptions, we recommend that you monitor and configure thresholds for the performance metrics of your RDS instances. If the value of a metric reaches the preset threshold, the system reports alerts. For more information, see Configure alert rules for an ApsaraDB RDS MySQL instance.
- If a single RDS instance of your database system is faulty, you can switch services over to another RDS instance. This operation is unavailable in the Basic Edition.
- In the multi-zone deployment solution, the primary instance can be switched to another zone if the current zone is faulty. In the single-zone deployment solution, you must wait until the fault is rectified or switch services over to the disaster recovery instance.
- If the region of your database system is faulty, you can switch services over to the disaster recovery instance. You also have the option to restore the data to a new RDS instance by using cross-region backup.
For more information about how to restore data, see the following topics: