Currently, only ApsaraDB for MySQL 5.6 supports the read-only instance.
In the business scenario that needs a small number of write requests but a large number of read requests to the database, a single instance may not be able to resist the read pressure, which even results in the effects on the main business. In order 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 use of read-only instances can meet the massive read requests to the database and help increase the application throughput.
The read-only instance is in a single-node architecture (no slave node) and uses the native replication capability of MySQL to synchronize changes in the master instance to all the relevant read-only instances. The read-only instance must be in the same region as that of the master instance, but they can be in the different zones.
A topology displaying the positioning of a read-only instance is shown as follows.
The billing method of read-only instance is Pay-As-You-Go.
Note: For the data retention strategy for read-only example instance, see Expiry/Arrears.
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, in order to facilitate easy elastic upgrading and downgrading.
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, including those for 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 including storage engine check, primary key check, large table check, as well as excessive indexing and missing indexing checks are supported.
Read-only instances have the following usage limitations.
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 creating 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 will 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.