Updated on 2025-11-11 GMT+08:00

Instance Guidelines

DB Instances

DB Instance Types

  • Primary/Standby
    • A primary/standby pair provides an HA architecture. It is suitable for production databases of large- and medium-sized enterprises in Internet, Internet of Things (IoT), retail e-commerce sales, logistics, gaming, and other sectors.
    • When a primary instance is being created, a standby instance is provisioned along with it to provide data redundancy. The standby instance is invisible to you after being created.
    • If a failover occurs due to a primary instance failure, there is a brief interruption between your database client and the instance. The client needs to be able to reconnect to the instance.
  • Single-node
    • A single-node architecture is more cost-effective than primary/standby pairs.
    • It is recommended for development and testing of microsites, and small- and medium-sized enterprises, or for learning about RDS.
    • If a fault occurs on a single instance, the instance cannot recover in a timely manner.

Database Connection

  • Configure RDS for MySQL parameters that match your workloads.
  • Keep an appropriate number of active connections.
  • Periodically release persistent connections because maintaining them may require a large cache and use up memory.

Reliability and Availability

  • Change instance classes during off-peak hours.
  • Select an instance class and storage space appropriate to your workloads.

Backup and Restoration

  • Set the backup cycle to All for write-intensive DB instances.
  • Before restoring tables to a specified point in time, check whether any large tables without primary keys were deleted before the selected point in time. If yes, it is difficult to estimate when the restoration can be complete.
  • If a DB instance is deleted, its automated full backups and binlog backups are also deleted. Create a manual backup of all data before deleting a DB instance.
  • Configure a custom recycling policy to ensure that any instances that are deleted by mistake can be rebuilt.

SQL Audit

  • Enable Audit Logging when periodic audits are required.
  • Enable SQL Explorer when SQL analysis is required.

Routine O&M

  • Periodically check the resource usage of DB instances. If the resources are insufficient, scale up the resources in a timely manner.
  • Monitor instance metrics. If any metric is beyond its expected range, address related issues as soon as possible.
  • Before deleting or modifying a record, run SELECT to check that it is the one you desire.