This topic provides an overview of read-only ApsaraDB RDS for SQL Server instances. If your application initiates a small number of write requests but a large number of read requests, a single primary instance may not be able to resist the read pressure. As a result, services may be affected. You can create one or more read-only instances to offload read requests from the primary instance and increase the throughput of your application.
- Read-only instances are supported only for RDS instances that run SQL Server 2017 on RDS Cluster Edition.
- Each read-only instance works in a single-node architecture, where no instances are provided as backups.
A read-only instance is billed on an hourly basis. The actual fee varies based on the instance type at the time of fee deduction. The following table describes the hourly rates of general-purpose instance types. Dedicated instance types are unavailable.
Hourly rates of general-purpose instance types and storage capacities
2 CPU cores, 4 GB
2 CPU cores, 8 GB
4 CPU cores, 8 GB
4 CPU cores, 16 GB
8 CPU cores, 16 GB
8 CPU cores, 32 GB
16 CPU cores, 64 GB
|China (Hong Kong)||$0.264||$0.522||$0.537||$0.993||$1.035||$2.02||$3.954||$0.0004/GB|
|US (Silicon Valley)||$0.292||$0.579||$0.595||$1.099||$1.146||$2.237||$4.378||$0.0003/GB|
|Malaysia (Kuala Lumpur)||$0.296||$0.586||$0.601||$1.112||$1.159||$2.262||$4.428||$0.0004/GB|
- Read-only instances use pay-as-you-go billing to reduce costs.
- Read-only instances reside in the same region as the primary instance, but possibly in different zones.
- The specifications of a read-only instance can differ from the specifications of the primary instance, and can be changed at any time. We recommend that the specifications of a read-only instance be higher than or equal to those of the primary instance. If the specifications of a read-only instance are lower than those of the primary instance, the read-only instance may have high latency or workloads.
- The network type of a read-only instance can differ from that of the primary instance.
- Read-only instances do not require database or account maintenance, because their database and account information is synchronized with the primary instance.
- A read-only instance automatically replicates the whitelists of the primary instance. However, the whitelists for the read-only instance are independent of those of the primary instance. For information about how to modify the whitelists of a read-only instance, see Configure a whitelist for an ApsaraDB RDS for SQL Server instance.
- Read-only instances support the monitoring and alerting for up to 20 performance metrics, such as the disk capacity, input/output operations per second (IOPS), number of connections, CPU utilization, and network traffic.
- You can create up to seven read-only instances.
- You cannot configure backup policies or manually create backups for read-only instances, because these are already configured or created on the primary instance.
- You cannot create a temporary read-only instance from a data backup file or a specific point in time, nor can you overwrite a read-only instance by using a data backup file.
- After a read-only instance is created, you cannot use a data backup file to restore it in overwrite mode.
- Data migration to read-only instances is not supported.
- Database creation and deletion are not supported.
- You cannot create or delete accounts, authorize accounts, or change the passwords of accounts on a read-only instance.
Can I manage accounts created in the primary instance from its read-only instances?
No, although accounts created on the primary instance are replicated to its read-only instances, you cannot manage the accounts on the read-only instances. The accounts only have read permissions on the read-only instances.