PolarDB for PostgreSQL(Compatible with Oracle) supports three modes of high availability: automatic, manual, and custom.
In automatic mode, PolarDB for PostgreSQL(Compatible with Oracle) detects the status of each database from multiple dimensions such as database kernels, containers, and hosts. PolarDB for Oracle helps reduce the exception detection time and the false positive rate. If a single point of failure (SPOF) occurs, the recovery time objective (RTO) is less than 30 seconds.
In manual mode, PolarDB for PostgreSQL(Compatible with Oracle) detects and reports the status of each database. You can determine whether to perform a failover to ensure high availability based on your business requirements.
In custom mode, you can define scenarios in which a failover is performed.
Intelligent read/write splitting
PolarDB for PostgreSQL(Compatible with Oracle) has a built-in intelligent database proxy named PolarProxy that provides advanced features. The advanced features include transparent read/write splitting and connection pools.
Consistency levels
- Eventual consistency: The system ignores the replication latency between a primary node and read-only nodes. This way, a maximum number of read requests can be routed to read-only nodes. This optimizes database performance.
- Session consistency: If you select eventual consistency and send write requests, the replication latency between the primary node and read-only nodes can cause data inconsistency in a session. Session consistency can be used to resolve this issue and can meet the requirements of most scenarios.
- Global consistency: Among the three consistency levels, global consistency ensures the highest level of consistency. The dependencies among sessions can cause data inconsistency. Global consistency can be used to resolve this issue.
Connection pools
- Session-level connection pools are transparent to your business. Frequent short-lived connections increase the loads in a PolarDB database. Session-level connection pools allow you to reduce the loads that are caused by frequent short-lived connections. The short-lived connections include PHP short-lived connections. This way, PolarDB can handle more requests.
- Transaction-level connection pools are used to reduce the number of direct connections to a database and the overhead that is caused by frequent thread-to-thread handovers. Transaction-level connection pools are suitable for serverless applications.
Transaction splitting
The transaction splitting feature allows you to split transactions that use the read committed isolation level. This feature routes a maximum of read requests to read-only nodes before write requests are sent. This offloads the workloads from the primary node. Transaction splitting is suitable for scenarios in which an object-relational mapping (ORM) framework is used to encapsulate all requests in one transaction by default.