RDS High-availability Edition runs ApsaraDB RDS for PostgreSQL instances in a primary/secondary architecture, providing automatic failover and a comprehensive feature set suitable for more than 80% of use cases across industries such as Internet, IoT, online retail, logistics, and gaming.
The secondary instance is a hot standby — it is not accessible to external clients.
Topology
How it works
Each RDS High-availability Edition instance consists of a primary node and a secondary node. The secondary node continuously replicates data from the primary. When the primary becomes unavailable, the system automatically fails over to the secondary without manual intervention.
The replication mode — semi-synchronous or asynchronous — is determined by the parameter template you select when creating the instance.
After a write operation completes on the primary, the transaction is committed only after the secondary acknowledges receipt of the log. The secondary does not need to replay the log before the commit is confirmed.
If the secondary becomes unavailable or a network interruption occurs between the two nodes, the mode automatically degrades to asynchronous.
The primary responds to the application immediately after a write operation completes, and replicates the data to the secondary in the background. This mode keeps primary workloads running even if the secondary is unavailable. However, if the primary fails before replication completes, data inconsistencies may occur between the two nodes.
Choose a replication mode
| Semi-synchronous | Asynchronous | |
|---|---|---|
| Commit timing | After secondary receives log | Immediately after primary write |
| Data loss risk | Lower (log received before commit) | Higher (unreplicated writes may be lost) |
| Degrades automatically | Yes — falls back to async if secondary is unavailable | N/A |
To change the replication mode after instance creation, see Query and change the data replication mode.
Deployment zones
Deploy the primary and secondary nodes in the same zone or in different zones within the same region. Cross-zone deployment provides cross-zone disaster recovery and improves overall availability.
The primary and secondary nodes must be in the same region.
If the secondary instance becomes unavailable, data of the primary instance is backed up in real time. As each backup nears completion, a FLUSH TABLE WITH READ LOCK (FTWRL) statement is executed, which holds a global lock for up to 5 seconds and places the primary in read-only mode during that period.
Features
RDS High-availability Edition includes auto scaling, backup and restoration, performance optimization, read/write splitting, and SQL Explorer. SQL Explorer retains logs of all executed statements for up to five years, enabling you to audit database activity and maintain data security.
Limitations
The primary and secondary nodes must be deployed in the same region.
The secondary node is not accessible to external clients. Direct connections can only be established to the primary node.
Downgrading from RDS High-availability Edition to RDS Basic Edition is not supported directly. To move to RDS Basic Edition, purchase a new RDS Basic Edition instance, migrate your data using DTS, then release the original instance. For migration instructions, see Use DTS to migrate data between ApsaraDB RDS for PostgreSQL instances. For release instructions, see Release or unsubscribe from an ApsaraDB RDS for PostgreSQL instance.
Upgrade from RDS Basic Edition
RDS Basic Edition runs in a standalone architecture with no hot standby. Instance failures, specification changes, and database engine upgrades can each cause extended downtime. For workloads that require high availability, use RDS High-availability Edition.
Upgrading from RDS Basic Edition to RDS High-availability Edition does not require data migration or reclaiming the original instance. For instructions, see Upgrade an ApsaraDB RDS for PostgreSQL instance from RDS Basic Edition to RDS High-availability Edition.
Create an RDS instance
For instructions on creating an RDS High-availability Edition instance, see Create an ApsaraDB RDS for PostgreSQL instance.
FAQ
Can I connect directly to the secondary instance?
No. Direct connections are only supported for the primary instance. The secondary serves as a hot standby and is not accessible externally.
Can I downgrade from RDS High-availability Edition to RDS Basic Edition?
No, not directly. Purchase a new RDS Basic Edition instance, migrate your data from the original instance using DTS, then release the original instance.
Does the replication mode change to asynchronous if the secondary handles heavier workloads than the primary?
Yes. If the secondary handles heavier workloads than the primary, the replication mode switches to asynchronous. For details, see Query and change the data replication mode.