For a business that needs a lesser number of write requests but a greater number of read requests to the database, a single instance might not resist the read pressure. It may affect the business operations. To achieve the elastic expansion of the read ability and to share the pressure of the database, you can create one or more read-only instances in a region. The read-only instances can handle massive read requests sent to the database and increase the application throughput.
A read-only instance is a read-only copy of the master instance. Changes in the master instance are also automatically synchronized to all relevant read-only instances through the native replication capability of MySQL. The read-only instance and the master instance must be in the same region, but they can be in the different zones.
The following topology displays the positioning of the read-only instance.
Currently, only the following ApsaraDB for RDS versions support read-only instances: MySQL 5.6 and MySQL 5.7 (excluding MySQL 5.7 Basic Edition)
A read-only instance is in a single-node architecture with no slave node.
The billing method of read-only instances is Pay-As-You-Go.
Read-only instances offer the following features:
The specifications of a read-only instance can differ from those of the master instance, and can be changed at any time, to facilitate easy elastic upgrade and downgrade.
Read-only instances support billing measured per hour, which is user-friendly and cost-efficient.
No account or database maintenance is required for a read-only instance. Both the account and database are synchronized through the primary instance.
Read-only instances support independent whitelist configuration.
Read-only instances support system performance monitoring.
Up to 20 system performance monitoring views can be used, which includes disk capacity, IOPS, connections, CPU utilization, and network traffic. Users can view the load of instances at ease.
Read-only instances provide optimization suggestions.
Optimization tools support storage engine check, primary key check, large table check, and excessive indexing and missing indexing checks.
Read-only instances have the following usage restrictions:
One master instance can only have five read-only instances.
Read-only instances do not support backup settings or temporary backup.
Read-only instances do not support the creation of temporary instances through backup files or any point in time backups.
Read-only instances do not support the overwriting of instances using backup sets.
After creating a read-only instance, the master instance does not support data recovery through the direct overwriting of instances using backup sets.
Data cannot be migrated to read-only instances.
Read-only instances do not support creating or deleting databases.
Read-only instances do not support creating or deleting account.
Read-only instances do not support authorizing account or modifying account password.