PolarDB-X high availability architecture achieves RPO=0. This topic describes the technical principles of how PolarDB-X implements high availability.
Technical principles
PolarDB-X uses a multi-replica data architecture (such as three or five replicas). To ensure strong consistency (RPO=0) between replicas, the Paxos majority replication protocol is used, which requires acknowledgment from more than half of the nodes for each write operation. Even if one node fails, the cluster can still provide services normally. The Paxos algorithm ensures strong consistency between replicas, completely eliminating replica inconsistency issues.
In PolarDB-X, data replicas are classified into two types based on the state of the data state machine: Normal and Logger. Furthermore, based on whether they participate in voting and election, replicas in a replication group can be further divided into the following roles:
|
Replica Role |
Role Type |
Description |
|
Leader |
Normal |
The leader is responsible for processing client requests and making decisions. The leader maintains logs to ensure data consistency and recoverability. |
|
Follower |
Normal |
The follower accepts and executes instructions from the leader. When the leader fails or becomes inaccessible, a follower can be elected as the new leader. |
|
Logger |
Logger |
The logger is similar to the follower role and only provides majority protocol services without providing data services. When the leader fails or becomes inaccessible, the logger participates in leader election voting and may temporarily be elected as a leader. However, it does not provide data services. After other majority follower replicas complete log synchronization, the logger proactively relinquishes the leader role. |
|
Learner |
Normal |
The learner can only passively receive system state information and cannot participate in voting or decision-making, which avoids impacting the system. |
Primary instance and read-only instance
-
Primary instance DN: Consists of 2 data replicas (Normal) + 1 log replica (Logger). Since the log replica (Logger) only stores logs without storing data, it requires very few resources. Therefore, this three-replica configuration can achieve costs close to the traditional primary-standby two-replica approach.
-
Read-only instance DN: Uses 1 data replica based on the Learner role to asynchronously synchronize data from the primary instance. It does not participate in the voting and decision-making of the Paxos protocol. Therefore, read-only instance failures do not affect the primary instance, meeting the requirement of fault isolation for read-only instances.
High availability disaster recovery
PolarDB-X provides multiple disaster recovery configurations for primary instance DNs based on Paxos multi-replica architecture:
|
Deployment Mode |
Replica Strategy |
Disaster Recovery Capability |
|
Single zone |
Three replicas (2 data replicas + 1 log replica) |
|
|
Three zones |
Three replicas (2 data replicas + 1 log replica) |
|
|
Geo-redundancy (two regions, three data centers) |
Five replicas (5 data replicas) |
|
PolarDB-X adapts the read-only instance DN configuration based on the disaster recovery configuration of the primary instance DN:
|
Primary Instance Deployment Mode |
Read-Only Instance Replica Strategy |
|
Single zone |
One replica. The region must be the same as the primary instance, but the zone can be different. |
|
Three zones |
|
|
Geo-redundancy (two regions, three data centers) |
One replica. The region must be the same as the primary region of the primary instance, but the zone can be different. |
High availability example:
