Overview of read-only ApsaraDB RDS for SQL Server instances - ApsaraDB RDS

This topic provides an overview of read-only ApsaraDB RDS for SQL Server instances. If your database system receives a small number of write requests but a large number of read requests, a single primary RDS instance may be overwhelmed by the read requests, and your workloads may be interrupted. To offload read requests from the primary RDS instance, you can create one or more read-only RDS instances. Read-only RDS instances help increase the read capability of your database system and the throughput of your application.

Description

When you create a read-only RDS instance, the system replicates data from the secondary RDS instance to the read-only RDS instance. After the read-only RDS instance is created, it has the same data as the primary RDS instance. If the data on the primary RDS instance is updated, the system automatically synchronizes the updates to all read-only RDS instances that are attached to the primary RDS instance.

Note

You can create read-only RDS instances for a primary RDS instance only when the primary instance runs SQL Server EE on RDS Cluster Edition.
Each read-only RDS instance runs based on a single-node architecture. In this architecture, no secondary read-only RDS instances are provided as standbys for the read-only RDS instance.

The following figure shows the topology of the primary RDS instance and its read-only RDS instances.

Scenarios

If the primary RDS instance is overloaded, you can create read-only RDS instances to offload read requests from the primary RDS instance.
If the primary RDS instance is temporarily unavailable due to backup or maintenance reasons, read requests are forwarded to its read-only RDS instances to support some of your workloads.
You can use read-only RDS instances to query and analyze a large amount of data in scenarios such as report analysis. This does not affect the primary RDS instance.
In emergency disaster recovery scenarios, you can use read-only RDS instances as backups for the primary RDS instance. However, do not directly switch the workloads of the primary RDS instance over to a read-only RDS instance.

Billing rules

Read-only RDS instances support the subscription and pay-as-you-go billing methods. For more information about the prices of read-only RDS instances, see Read-only ApsaraDB RDS instance types.

Highlights

Billing methods: Read-only RDS instances support both the pay-as-you-go and subscription billing methods. The pay-as-you-go billing method is flexible and allows you to release your read-only RDS instances when the RDS instances are no longer needed. The subscription billing method is cost-effective for long-term commitments.
Regions and zones: Read-only RDS instances reside in the same region as the primary RDS instance, but can reside in different zones.
Instance specifications: The specifications of read-only RDS instances can differ from the specifications of the primary RDS instance. You can change the specifications of read-only RDS instances at any time. We recommend that you specify an instance type whose specifications are higher than or equal to the specifications of the instance type of the primary RDS instance. If the specifications of the read-only RDS instance are lower than the specifications of the primary RDS instance, the read-only RDS instance may encounter issues such as high latency and heavy load.
Network type: The network types of read-only RDS instances can differ from the network type of the primary RDS instance. For more information, see Change the network type of an ApsaraDB RDS for MySQL instance.
Account and database management: The accounts and databases on read-only RDS instances are synchronized from the primary RDS instance. You do not need to manage databases or accounts on read-only RDS instances.
Management of IP address whitelists: When you create a read-only RDS instance, the system replicates the IP address whitelists of the primary RDS instance to the read-only RDS instance. However, the IP address whitelists of the read-only RDS instance are independent of the IP address whitelists of the primary RDS instance. If you want to modify the IP address whitelists of a read-only RDS instance, follow the instructions provided in Configure an IP address whitelist for an ApsaraDB RDS for SQL Server instance.
Monitoring and alerting: Read-only RDS instances support monitoring and alerting. You can monitor near 20 metrics, such as disk usage, IOPS, number of connections, CPU utilization, and network traffic.
Number of read-only RDS instances: You can create up to seven read-only RDS instances for a primary RDS instance.

Limits

Instance backup: You cannot configure backup policies or manually create backups for read-only RDS instances. These are configured and created on the primary RDS instance. You cannot create temporary RDS instances from backup files or any point in time. You cannot overwrite RDS instances by using backup sets. After a read-only RDS instance is created, you cannot use backup sets to overwrite the primary RDS instance to restore data.
Data migration: You cannot migrate data to read-only RDS instances.
Database management: You cannot create or delete databases on read-only RDS instances.
Account management: You cannot create or delete accounts, grant permissions to accounts, or change the passwords of accounts on read-only RDS instances.

FAQ

Can I change the billing method of my read-only RDS instance?
Yes, you can change the billing method of a read-only RDS instance. For more information, see Switch an ApsaraDB RDS for SQL Server instance from pay-as-you-go to subscription or Switch an ApsaraDB RDS for SQL Server instance from subscription to pay-as-you-go.
After I change the configuration of my read-only RDS instance, release the read-only RDS instance, or change the billing method of the read-only RDS instance, is the primary RDS instance affected?
No, the primary RDS instance is not affected.
After I create accounts on my primary RDS instance, can I manage the accounts on the read-only RDS instances of my primary RDS instance?
No, you cannot manage the accounts on the read-only RDS instances. The accounts that are created on your primary RDS instance are synchronized to the read-only RDS instances and have only the read permissions on the read-only RDS instances.
If my primary RDS instance fails, can I convert a read-only RDS instance to a regular RDS instance?
No, you cannot convert a read-only RDS instance to a regular RDS instance.
Do read-only RDS instances support manual backup or automatic backup?
No, read-only RDS instances do not support manual backup or automatic backup. Backups are performed on the primary RDS instance. You cannot configure backup settings or manually create backups for read-only RDS instances.
Do read-only RDS instances support parallel replication?
Yes, read-only RDS instances support parallel replication. By default, ApsaraDB RDS for SQL Server uses parallel replication.
What mechanism is used to clear transaction logs?
The transaction logs of an RDS instance are cleared in the following phases:
- Log truncation: Log truncation is automatically performed for each log backup. If long-running transactions are executed, synchronization waits occur, or kernel-related issues occur, log truncation cannot take effect.
- Log shrinking: Regular backups include log shrinking. You can also shrink logs in the ApsaraDB RDS console. For more information, see Shrink the transaction logs of an ApsaraDB RDS for SQL Server instance.
How is data replicated to read-only RDS instances? What causes a replication latency and how do I resolve the issue? How do I view a replication latency?
When you create a read-only RDS instance, data is replicated from the secondary RDS instance to the read-only RDS instance. The data of the created read-only RDS instance is the same as the data of the primary RDS instance. Data updates on the primary RDS instance are automatically synchronized to all the read-only RDS instances that are attached to the primary RDS instance.
The following section describes the causes and solutions:
- Cause: The specifications of the primary RDS instance are higher than the specifications of the read-only RDS instance. In this case, the replication latency between your primary and read-only RDS instances is large.
  Solution: Upgrade the specifications of the read-only RDS instance. For more information, see Change the specifications of an ApsaraDB RDS for SQL Server instance.
- Cause: Large concurrent transactions exist.
  Solution: Check and process large transactions. In most cases, large transactions are caused by locks, slow queries, and uncommitted temporary queries.
- Cause: The kernel is abnormal.
  Solution: Upgrade the major engine version or update the minor engine version of your RDS instance. For more information, see Upgrade the major engine version and RDS edition of an ApsaraDB RDS for SQL Server instance or Update the minor engine version of an ApsaraDB RDS for SQL Server instance.
You can use autonomy services in ApsaraDB RDS for SQL Server to identify issues and view the replication latency. You can also execute the following statements to view the replication latency. For more information, see Overview of DAS.
```
SELECT
    ag.name AS [availability_group_name]
    , d.name AS [database_name]
    , ar.replica_server_name AS [replica_instance_name]
    , drs.truncation_lsn
    , drs.log_send_queue_size
    , drs.redo_queue_size
FROM
    sys.availability_groups ag
    INNER JOIN sys.availability_replicas ar
        ON ar.group_id = ag.group_id
    INNER JOIN sys.dm_hadr_database_replica_states drs
        ON drs.replica_id = ar.replica_id
    INNER JOIN sys.databases d
        ON d.database_id = drs.database_id
WHERE drs.is_local=0
ORDER BY
    ag.name ASC, d.name ASC, drs.truncation_lsn ASC, ar.replica_server_name ASC
```