Relational Database ServiceRelational Database Service

Compute
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
Domain Name Service
VPC Endpoint
Cloud Connect
Enterprise Switch
Security & Compliance
Anti-DDoS
Web Application Firewall
Host Security Service
Data Encryption Workshop
Database Security Service
Advanced Anti-DDoS
Data Security Center
Container Guard Service
Situation Awareness
Managed Threat Detection
Compass
Cloud Certificate Manager
Anti-DDoS Service
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GaussDB NoSQL
GaussDB(for MySQL)
Distributed Database Middleware
GaussDB(for openGauss)
Developer Services
ServiceStage
Distributed Cache Service
Simple Message Notification
Application Performance Management
Application Operations Management
Blockchain Service
API Gateway
Cloud Performance Test Service
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
DevCloud
ProjectMan
CodeHub
CloudRelease
CloudPipeline
CloudBuild
CloudDeploy
Cloud Communications
Message & SMS
Cloud Ecosystem
Marketplace
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP License Service
Support Plans
Customer Operation Capabilities
Partner Support Plans
Professional Services
enterprise-collaboration
Meeting
IoT
IoT
Intelligent EdgeFabric
DeveloperTools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Updated at: Apr 02, 2022 GMT+08:00

Specifications on Using RDS for MySQL Instances

DB Instances

DB Instance Type

  • Primary/Standby
    • A primary/standby instance uses 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 synchronously 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. You need to reconnect the client to the instance.
  • Single
    • A single instance uses a single-node architecture, which is more cost-effective than primary/standby instances.
    • It is suitable 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.

Instance Class

  • Dedicated
    • CPU and memory resources are dedicated for use and performance is stable without being affected by other instances on the same physical machine. This instance class is suitable for scenarios that require high performance stability.
  • 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 cost-effective and is suitable for scenarios that have low requirements on performance stability.

Read Replica

  • A read replica is a single-node instance. If the physical server hosting a read replica is faulty or database replication between the read replica and its primary instance is abnormal, it takes a long time to rebuild and restore the read replica (depending on the data volume).
  • Database proxy is recommended for read-intensive workloads. Before using database proxy, ensure that you have purchased more than one read replica. If a single read replica is faulty, database proxy can distribute traffic to other read replicas.

Database Connection

  • Configure RDS for MySQL parameters for your workloads.
  • Keep an appropriate number of active connections.
  • Release persistent connections periodically because maintaining persistent connections may generate large cache and cause high memory consumption.

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 class during off-peak hours.
  • Select instance class and storage space suiting your workload.
  • After scaling up your primary 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 backup during off-peak hours and change the backup time window (default setting: 03:00-04: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 the backup retention period as required. 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 table without a primary key was deleted before the selected time point. If yes, it is difficult to estimate the restoration time.
  • Select a storage type as required before creating a DB instance. Backups cannot be restored to existing or original instances for DB instances using local SSDs.
  • 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.
  • Customize the recycling policy to ensure that the instances that are deleted by mistake can be rebuilt.

SQL Audit

  • Enable Audit Log 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 service 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 value 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.

Did you find this page helpful?

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?







Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel