Read-only RDS instances

Overview

When you create a read-only RDS instance, the system replicates data from the secondary RDS instance to the read-only RDS instance. This prevents interruptions to your workloads that are run on the primary RDS instance. If the data on the primary RDS instance is updated, the updates are automatically synchronized to all read-only RDS instances.

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 process read requests. This helps offload the read requests from the primary RDS instance.

• If a primary RDS instance is temporarily unavailable due to backup or maintenance reasons, you can use read-only RDS instances to process read requests. This helps ensure business continuity.

• 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.

• If the read/write splitting feature is used, you can use read-only RDS instances to prevent read/write lock contention and improve the system performance and throughput.

Billing rules

Read-only RDS instances support the subscription and pay-as-you-go billing methods. For more information about the fee for a subscription read-only RDS instance, visit the ApsaraDB RDS buy page. For more information about the fee for a pay-as-you-go read-only RDS instance, see Read-only instance types.

Highlights

• Regions and zones: Read-only RDS instances reside within the same region as the primary RDS instance but can reside in different zones.

• Network type: The network types of read-only RDS instances can be different from the network type of the primary RDS instance. For more information, see Change the network type.

• 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 automatically 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, you can follow the instructions provided in Configure an IP whitelist.

• Monitoring and alerting: You can monitor the performance metrics of a read-only RDS instance. The metrics include the disk usage, IOPS, number of connections, and CPU utilization. The monitoring data of the metrics is provided in charts.

• Read/write splitting: The read/write splitting feature works with the database proxy feature to allow the system to forward write requests to the primary RDS instance and read requests to the read-only RDS instances. This reduces the loads on the primary RDS instance. For more information about how to enable the database proxy feature for a primary RDS instance, see What are database proxies?

• Number of read-only RDS instances: If the primary RDS instance uses cloud disks, you can create up to 32 read-only RDS instances. If the primary RDS instance uses Premium Local SSDs, you can create up to 5 read-only RDS instances.

Usage notes

• Data backup: You cannot configure backup policies or manually create backups for read-only RDS instances. These operations are performed on primary RDS instances.

• Data migration: You cannot migrate data to read-only RDS instances.

• Database management: You cannot create or delete databases.

• Account management: You cannot create accounts, grant permissions to accounts, change the passwords of accounts, or delete accounts on read-only RDS instances.

• Specifications and storage capacity:

  • If the primary RDS instance uses cloud disks, the storage capacity of a read-only RDS instance must be greater than or equal to the storage capacity of the primary RDS instance. If the memory capacity of the primary RDS instance is greater than the memory capacity of a read-only RDS instance, the read-only RDS instance restarts during the specification change of the primary RDS instance.

  • If the primary RDS instance uses Premium Local SSDs, the specifications and storage capacity of its read-only RDS instances cannot be lower than the specifications and storage capacity of the primary RDS instance.

• If a read-only RDS instance encounters unexpected errors, such as failures to replicate database engine settings, the system rebuilds the read-only RDS instance.

• After the primary RDS instance is released, the subscription read-only RDS instances of the primary RDS instance are automatically refunded and released, and the pay-as-you-go read-only RDS instances of the primary RDS instance are directly released.

FAQ

• Q: Can I change the billing method of a read-only instance?

  A: Yes. For more information, see Change the billing method of an instance from pay-as-you-go to subscription or Change the billing method of an instance from subscription to pay-as-you-go.

• Q: Does changing the configurations, releasing, or changing the billing method of a read-only instance affect the primary instance?

  A: No, these actions do not affect the primary instance.

• Q: Can I use the accounts created on the primary instance to access the read-only instance?

  A: Yes. Accounts from the primary instance are synchronized to the read-only instance but cannot be managed there. These accounts have read-only permissions on the read-only instance.

• Q: Can I convert a read-only instance into a regular instance, for example, for disaster recovery?

  A: No, this is not supported.

• Q: Can I back up data on a read-only instance? Can automatic backups be performed on the read-only instance?

  A: No. Backups are not required for read-only instances. All backups are performed on the primary instance.

• Q: Does the read-only instance support parallel replication?

  A: ApsaraDB RDS for PostgreSQL uses physical streaming replication, which relies on WAL log synchronization and replay to replicate data. This method is highly efficient and does not require parallel replication.

• Q: How are transaction logs cleared?

  A: After an ApsaraDB RDS for PostgreSQL WAL log backup is complete, the kernel automatically clears the logs during a checkpoint operation.

• Q: How can I determine if replication is normal based on the replication latency?

  A: Normally, replication latency is under one second. Latency greater than one second indicates a data synchronization delay. In extreme cases, the replication may be disconnected.

• Q: What are the common causes of replication latency?

  A: The common causes and their solutions are as follows:

  • Cause 1: The read-only instance has significantly lower specifications than the primary instance, which can cause high replication latency.

    Solution: Upgrade the read-only instance's instance type. For more information, see Change instance specifications.

  • Cause 2: The max_standby_streaming_delay parameter is not configured properly, which causes high replication latency. For information about how to set parameters, see Modify the parameters of an ApsaraDB RDS for PostgreSQL instance.

    Solution: Adjust the value of the max_standby_streaming_delay parameter:

    • A small value reduces replication latency between the read-only instance and the primary instance, but may cause transactions on the read-only instance to be canceled.

    • An excessively large value may cause high replication latency.