This topic describes how to create a read-only RDS instance for a primary ApsaraDB RDS for PostgreSQL instance to increase the read capability of your database system and the throughput of your application. In ApsaraDB RDS for PostgreSQL, physical replication is implemented to replicate the primary RDS instance to generate a read-only RDS instance. This way, the data on the read-only RDS instance is the same as the data on the primary RDS instance. When the data on the primary RDS instance is updated, data updates are automatically synchronized to the read-only RDS instance.
For more information about read-only RDS instances, see Overview of read-only ApsaraDB RDS for PostgreSQL instances.
Prerequisites
A primary RDS instance is created, and the RDS instance meets the following requirements:
- The primary RDS instance runs PostgreSQL 10 or later.
- The primary RDS instance runs RDS High-availability Edition.
- The instance type of the primary RDS instance meets the following requirements:
- If the primary RDS instance uses cloud disks, no limits are imposed on the instance type.
- If the primary RDS instance uses local disks, the instance must use a dedicated instance type that provides at least 8 CPU cores and 32 GB of memory.
Usage notes
- You can create only read-only RDS instances that belong to the same instance family as the primary RDS instance. For example, if the primary RDS instance belongs to a general-purpose instance family, you can create only read-only RDS instances of the general-purpose instance family. For more information, see Primary ApsaraDB RDS for PostgreSQL instance types and Read-only ApsaraDB RDS for PostgreSQL instance types.
- You can create read-only RDS instances for the primary RDS instance. You cannot convert existing RDS instances to read-only RDS instances.
- When you create a read-only RDS instance, ApsaraDB RDS replicates data from the secondary RDS instance to the read-only RDS instance. This prevents interruptions to your workloads on the primary RDS instance.
- A read-only RDS instance does not inherit the parameter settings of the primary RDS instance. Default parameter settings are generated for the read-only RDS instance. You can modify the default parameter settings in the ApsaraDB RDS console. Important Read-only RDS instances that use new general-purpose instance types inherit the parameter settings of the primary RDS instance. For more information about read-only RDS instances that use new general-purpose instance types, see Read-only ApsaraDB RDS for PostgreSQL instance types.
- The storage type of the read-only RDS instance is the same as the storage type of the primary RDS instance.
- If the primary RDS instance uses 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 the primary RDS instance uses standard SSDs or enhanced SSDs (ESSDs), we recommend that you make sure the specifications of its read-only RDS instances are the same as the specifications of the primary RDS instance or are higher than or equal to 50% of the specifications of the primary RDS instance. This helps prevent replication latency and out of memory (OOM) errors that are caused by a significant performance difference between the primary RDS instance and its read-only RDS instances.
- If the primary RDS instance uses standard SSDs or ESSDs, you must make sure that the storage capacity of its read-only RDS instance is 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 its read-only RDS instance and you change the specifications of the primary RDS instance, the read-only RDS instance is restarted.
- If the primary RDS instance uses local SSDs, you can create up to five read-only RDS instances. If the primary RDS instance uses standard SSDs or ESSDs, you can create up to 32 read-only RDS instances.
- If the primary RDS instance uses local SSDs, its read-only RDS instances run in high-availability mode. If the primary RDS instance uses standard SSDs or ESSDs, its read-only RDS instances run in single-node mode. Note In the standalone architecture, no secondary RDS instances are provisioned, and the availability cannot be ensured. We recommend that you purchase multiple read-only RDS instances and use libpq or Java Database Connectivity (JDBC) to implement automatic failover. You can also use the database proxy feature to implement automatic read/write splitting. For more information, see Configure automatic failover and read/write splitting and What are database proxies?.
- You are charged for the read-only RDS instances that you create based on the subscription billing method or the pay-as-you-go billing method. 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 ApsaraDB RDS instance types.
Create a read-only RDS instance
- Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.
- In the Distributed by Instance Role section of the page that appears, click Add to the right of Read-only Instance. Note If you are using the original ApsaraDB RDS console, click Create Read-only Instance in the Distributed by Instance Role section of the Basic Information page.
- Configure the following parameters.
Parameter Description Billing Method - Subscription: A subscription instance is an instance for which you pay an upfront fee. If you want to use the read-only RDS instance for a long period of time, we recommend that you select the subscription billing method. If you select the subscription billing method, you must specify a subscription period.
- Pay-As-You-Go: A pay-as-you-go instance is an instance for which you are charged per hour based on your resource usage. If you want to use the read-only RDS instance for a short period of time, we recommend that you select the pay-as-you-go billing method. You can create a pay-as-you-go read-only RDS instance. After you confirm that the created read-only RDS instance meets your business requirements, you can change the billing method of the read-only RDS instance from pay-as-you-go to subscription.
Zone The zone to which the read-only RDS instance belongs. Each zone is an independent physical location within a region. Zones in the same region do not have substantial differences. The multi-zone deployment method supports zone-disaster recovery. Instance Type - General-purpose (Entry-level): allows you to select a general-purpose instance type. A general-purpose RDS instance exclusively occupies the allocated memory and I/O resources. However, it shares CPU and storage resources with other general-purpose instances that are deployed on the same host.
- Dedicated (Enterprise-level): allows you to select a dedicated instance type or a dedicated host instance type. A dedicated RDS instance exclusively occupies the allocated CPU, memory, storage, and I/O resources. Dedicated host instance types provide the highest specifications in the dedicated instance family. A dedicated host RDS instance exclusively occupies all CPU, memory, storage, and I/O resources on the host on which the instance is deployed.
Note Select the instance type to which you want to upgrade. Each instance type supports a specific number of CPU cores, memory capacity, maximum number of connections, and maximum IOPS. If the primary RDS instance uses local SSDs, the specifications of a read-only RDS instance must be higher than or equal to the specifications of the primary RDS instance. For more information about the instance types, see Read-only ApsaraDB RDS for PostgreSQL instance types.Capacity The maximum amount of storage that is allocated to store data files, system files, write-ahead logging (WAL) files, and transaction files in the read-only RDS instance. You can adjust the storage capacity at a step size of 5 GB. NoteFor more information about the storage capacity range that is supported by each instance type, see Read-only ApsaraDB RDS for PostgreSQL instance types.- If the primary RDS instance uses standard SSDs or ESSDs, you must make sure that the storage capacity of its read-only RDS instance is 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 the read-only RDS instance and you change the specifications of the primary RDS instance, the read-only RDS instance is restarted.
- If the primary RDS instance uses local SSDs, the storage capacity of a read-only RDS instance must be greater than or equal to the storage capacity of the primary RDS instance.
- Click Next: Instance Configuration and configure the following parameters.
Parameter Description Network Type The network type of the read-only RDS instance, which is the same as the network type of the primary RDS instance. If the primary RDS instance uses the VPC network type, make sure that the primary and read-only RDS instances reside in the same VPC. - Click Next: Confirm Order.
- Read and select Terms of Service, click Pay Now, and then complete the payment.
- If the primary RDS instance uses local SSDs, the amount of time that is required to create a read-only RDS instance is approximately 10 minutes plus the amount of time that is required for a full backup.
- If the primary RDS instance uses standard SSDs, the amount of time that is required to create a read-only RDS instance is approximately 20 minutes plus the amount of time that is required for a full backup.
- If the primary RDS instance uses ESSDs, the amount of time required to create a read-only RDS instance is approximately 20 minutes.
- When you create a read-only RDS instance, the primary RDS instance is not affected. After the read-only RDS instance is created, a WAL Sender process is generated in the primary RDS instance and is used to send WAL files to the read-only RDS instance.
- In ApsaraDB RDS for PostgreSQL, snapshots are used to create read-only RDS instances, regardless of the data volume.
View a read-only RDS instance
- To view a read-only RDS instance on the Instances page, perform the following steps:
- Log on to the ApsaraDB RDS console. In the left-side navigation pane, click Instances. In the top navigation bar, select the region in which your RDS instance resides.
- Find the read-only RDS instance and click the instance ID.
- To view a read-only RDS instance on the Basic Information page of the primary RDS instance, perform the following steps:
- Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.
- On the Basic Information page of the primary RDS instance, move the pointer over the number of read-only RDS instances and click the ID of the read-only RDS instance that you want to view.
View the data replication latency for a read-only RDS instance
A read-only RDS instance may synchronize data from the primary RDS instance at a specific latency. You can go to the Basic Information page of a read-only RDS instance to view the latency of data replication to the instance.

Related operations
Operation | Description |
---|---|
Create a read-only instance | Creates a read-only instance. |
FAQ
- Can I change the billing method of a 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 PostgreSQL instance from pay-as-you-go to subscription or Change the billing method of an ApsaraDB RDS instance from subscription to pay-as-you-go.
- If I change the configuration of a read-only RDS instance, release the read-only RDS instance, or change the billing method of the read-only RDS instance, does the primary RDS instance to which the read-only RDS instance is attached is affected?
A: 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 read permissions on the read-only RDS instances.
- Can a read-only RDS instance be converted into a regular RDS instance, such as a disaster recovery RDS instance?
No, a read-only RDS instance cannot be converted into a regular RDS instance.
- Can I back up the data of a read-only RDS instance? Do read-only RDS instances support automatic backup?
You do not need to back up read-only RDS instances. Backups are performed on the primary RDS instance. In ApsaraDB RDS for PostgreSQL, snapshot backups are used, and no performance overhead is caused on the primary RDS instance.
- Do read-only RDS instances support parallel replication?
In ApsaraDB RDS for PostgreSQL, physical replication is used to synchronize data. Physical replication uses WAL files for data synchronization and playback, which is more efficient than parallel replication.
- How are transaction logs cleared?
After the WAL files of an RDS instance are backed up, the kernel clears the transaction logs during checkpointing.
- How do I determine whether replication is normal based on the latency of data replication for a read-only RDS instance?
In most cases, if the latency of data replication for a read-only RDS instance is less than or equal to 1 second, the data replication is implemented as expected. If the latency of data replication for a read-only RDS instance is greater than 1 second, the data is replicated at a specific latency, and disconnection may occur.
- What causes a replication latency between a primary RDS instance and a read-only RDS instance? The following section describes the common causes and solutions:
- Cause: The specifications of the primary RDS instance are higher than the specifications of the read-only RDS instance.
Solution: Upgrade the specifications of the read-only RDS instance. For more information, see Change the specifications of an ApsaraDB RDS for PostgreSQL instance.
- Cause: A large number of transactions are executed on the primary RDS instance, which causes the accumulation of WAL files.
Solution: We recommend that you do not execute large transactions on the primary RDS instance. Alternatively, split large transactions into small transactions.
- Cause: The specifications of the primary RDS instance are higher than the specifications of the read-only RDS instance.