Instance Usage Suggestions

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 enterprises in the 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, your database client will be disconnected for a short period of time. The client needs to be able to reconnect to the instance.
• Single
  • A single-node architecture is more cost-effective than primary/standby pairs.
  • It is only recommended for development and testing of microsites, and small and medium enterprises, or for learning about RDS.
  • If a fault occurs on a single instance, the instance cannot recover in a timely manner.
• Read replica

  Read replicas include single read replicas and HA read replicas.

  • Single read replica

    If you want to use single read replicas, you are advised to buy more than one single read replica and enable database proxy. By doing so, the database proxy can route traffic to other read replicas if a read replica is faulty.

  • HA read replica

    If the physical server where the primary read replica is deployed fails, the standby read replica automatically takes over workloads.

  When you purchase a read replica, select the same value for Table Name as the DB instance.

  Recommendations for using read replicas:

  1. Configure no more than two HA read replicas for a DB instance.
  2. If your DB instance is associated with more than two read replicas, enable database proxy for cost-effectiveness.
  

  If the replication between a read replica (single or HA) and the DB instance is abnormal, it can take a long time to rebuild and restore the read replica (depending on the data volume).

  After a read replica is created, you can change its time zone by adjusting the time_zone parameter. Ensure that the read replica uses the same time zone as the primary instance to avoid data synchronization errors.

Instance Classes

• Dedicated

  The instance has dedicated CPU and memory resources to ensure stable performance. The performance of a dedicated instance is never affected by other instances on the same physical machine. This instance class is good when performance stability is important.

• General-purpose

  CPU resources are shared with other general-purpose DB instances on the same physical machine. CPU usage is maximized through resource overcommitment. This instance class is a cost-effective option and suitable for scenarios where performance stability is not critical.

Database Connection

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

Reliability and Availability

• Select primary/standby DB instances for production databases.
• Deploy primary and standby instances in different AZs.
• Create read replicas and enable read/write splitting for workloads involving frequent read/write operations.
• Change instance classes during off-peak hours.
• Select an instance class and storage space appropriate to your workloads.
• After scaling up your DB instance, scale up its read replicas in a timely manner to prevent service exceptions caused by insufficient storage of read replicas.

Backup and Restoration

• Perform manual backups during off-peak hours and change the backup time window (default setting: 01:00-02:00 (GMT+08:00)) for automated backup as required.
• Set the backup cycle to All for DB instances that process many write requests every day.
• Configure a backup retention period suited to your service demands. The default value is 7 days.
• Set the local retention period of binlogs as required. The default value is 0, indicating that local binlogs are deleted once they are successfully backed up to OBS.
• 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.
• Select the right storage type before creating a DB instance. DB instances using local SSDs cannot be restored to existing instances.
• If a DB instance is deleted, its automated full backups and binlog backups are also deleted. Perform manual backup for 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 slow query logs and error logs to identify problems in advance.
• 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.
• Run the SELECT statement before deleting or modifying a record.

Security

• Prevent your database from being accessed from the Internet. If you want to allow the access from the Internet, bind an EIP to your DB instance and configure a whitelist.
• Use SSL to connect to your DB instance.