Create a PostgreSQL read-only instance

Prerequisites

You have created a primary ApsaraDB RDS for PostgreSQL instance that meets the following requirements:

• Instance Version: The primary instance must run a version that is currently available for purchase. Discontinued versions do not support the creation of read-only instances.

• Edition: High-availability Edition.

• Instance type:

  • Instances that use cloud disks: No special requirements.

  • Instances that use high-performance local disks: The instance type must be a dedicated type with at least 8 vCPUs and 32 GB of memory.

• Billing method: The instance must use the subscription or pay-as-you-go billing method. Serverless instances do not support the creation of read-only instances.

Considerations

• The read-only instance must be in the same VPC as the primary instance. Otherwise, creation fails, and a refund is issued.

• You can only create new read-only instances from a primary instance. You cannot convert an existing instance into a read-only instance.

• Creating a read-only instance does not affect the primary instance because data is replicated from the primary instance's secondary instance.

• A read-only instance does not inherit parameters from the primary instance. Instead, it uses default parameter values. You can modify these parameters in the console for the read-only instance.

  Important

  The parameters of a new general-purpose read-only instance are inherited from the primary instance. For more information about new general-purpose read-only instances, see ApsaraDB RDS for PostgreSQL read-only instance types.

• The storage type of the read-only instance must be the same as that of the primary instance.

• A read-only instance that uses a high-performance local disk cannot have an instance type or storage capacity smaller than the primary instance.

• For a read-only instance that uses cloud disks, we recommend that you select an instance type that is the same as, or has at least half the resources of, the primary instance. This helps prevent issues such as high replication latency or out-of-memory (OOM) errors caused by a significant performance gap.

• If the primary instance has more memory than the read-only instance, the read-only instance is restarted when you change the primary instance's configurations.

• The memory of the read-only instance you create must meet the following requirements:

  Primary instance memory	Read-only instance memory
  (0 GB, 64 GB]	At least 1/4 of the memory of the primary instance
  (64 GB, 256 GB]	At least 1/6 of the memory of the primary instance
  (256 GB, 9999 GB]	At least 1/8 of the memory of the primary instance

• You can create a maximum of 5 read-only instances for a primary instance that uses high-performance local disks, and a maximum of 32 read-only instances for a primary instance that uses cloud disks.

• Read-only instances for a primary instance that uses high-performance local disks are of High-availability Edition. Read-only instances for a primary instance that uses cloud disks can be of Basic Edition or High-availability Edition.

  Note

  Basic Edition uses a single-node architecture and does not have a standby node. Therefore, it cannot ensure high availability. We recommend that you purchase multiple read-only instances and use libpq or JDBC to implement automatic failover, or use a database proxy to implement automatic read/write splitting. You can also directly purchase a High-availability Edition read-only instance.

• Creating a read-only instance incurs fees. The subscription and pay-as-you-go billing methods are supported. For information about fees, see the buy page.

Create a read-only instance

1. Go to the ApsaraDB RDS instance list page. In the top navigation bar, select your instance's region. Then, click the instance ID.

2. In the Instance Distribution section, click Add next to Read-only Instance.

   

3. Configure the parameters for the read-only instance.

   Parameter	Description
   Billing Method	Subscription: A prepaid billing method suitable for long-term use. Pay-as-you-go: A postpaid billing method suitable for short-term use. You are charged on an hourly basis. You can create a pay-as-you-go read-only instance and then change its billing method to subscription if it meets your requirements.
   Edition	Basic Edition: A cost-effective, single-node read-only instance suitable for learning or testing. Fault recovery and restarts can be slow. High-availability Edition (Default): A dual-node architecture with a primary and a standby node. Recommended for production environments, this edition ensures high availability for the read-only instance and meets most use case requirements. Note If you select High-availability Edition for the Edition parameter, you must also specify the primary zone, deployment method (multi-zone or single-zone), and secondary zone.
   Product Type	You can select Yitian Edition only if the Storage Type of the primary instance is ESSD or high-performance cloud disk. For more information about General-purpose Edition and Yitian Edition, see Product types.
   Zone	A zone is an independent physical area within a region. There are no significant differences among zones in the same region. A multi-zone deployment provides zone-level disaster recovery.
   Instance Type	General-purpose: An instance type that provides shared resources. You have exclusive access to the allocated memory and I/O resources, but share CPU and storage resources with other general-purpose instances on the same server. Dedicated: An instance type that provides exclusive resources. You have exclusive access to the allocated CPU, memory, storage, and I/O resources. The top-tier dedicated instance type exclusively occupies an entire server. Note Each instance type has specific vCPU cores, memory, maximum connections, and maximum IOPS. For a primary instance that uses high-performance local disks, the instance type of its read-only instances cannot be lower than that of the primary instance. For more information, see ApsaraDB RDS for PostgreSQL read-only instance types.
   Storage Capacity	Storage capacity includes space for data, system files, WAL files, and transaction files. You can adjust the storage in 5 GB increments. Note The storage capacity of a read-only instance cannot be smaller than that of the primary instance. For information about the storage capacity of each instance type, see ApsaraDB RDS for PostgreSQL read-only instance types.

4. Click Next: Instance Configurations and configure the following parameters.

   Parameter	Description
   Network Type	By default, this is the same as the network type, VPC, and vSwitch of Primary Node of the primary instance.
   Release Protection	If the billing method is pay-as-you-go, you can enable Release Protection for the instance to prevent it from being accidentally released. For more information, see Enable and disable release protection.
   Resource Group	By default, this is the same as the resource group of the primary instance and cannot be modified.
   Time Zone	By default, this is the same as the time zone of the primary instance.
   SLR Authorization	You do not need to configure this parameter. The authorization was granted when you created the primary instance. For more information about SLR authorization, see [Product/Feature Change] SLR authorization is required to create ApsaraDB RDS for PostgreSQL instances from October 10, 2022.
   Instance name	Specify a name for the instance for easy identification and management.
   Tags	You can add a tag to the instance during creation and later filter instances by tags. For more information, see Filter instances by tag.

5. Click Next: Confirm Order.

6. Confirm the Parameters, select the Quantity and Duration (for subscription instances only), and then click Pay Now to complete the payment.

View a read-only instance

View replication latency

A delay may occur when a read-only instance synchronizes data from the primary instance. You can view the replication latency on the Basic Information page of the read-only instance.

API reference

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.