All Products
Search
Document Center

PolarDB:Overview

Last Updated:May 31, 2024

The PolarDB-X high availability architecture is designed to ensure a recovery point objective (RPO) of 0 in the event of a disaster. This topic provides an overview of the PolarDB-X high availability feature.

Multi-replica architecture

PolarDB-X adopts a multi-replica architecture that uses multiple data replicas such as three or five replicas. To ensure consistency between replicas (RPO=0), the architecture uses the Paxos majority consensus replication protocol, which requires that each write operation must be acknowledged by more than half of the nodes. This way, the cluster can continue to provide services without interruption even if a node fails. Paxos can ensure strong consistency by eliminating inconsistency issues among replicas.

In PolarDB-X, data replicas are classified into two categories based on their roles in the data state machine: normal replicas and logger replicas. The replicas within a replication group can be further classified into the following roles based on whether the replicas participate in leader elections.

Replica role

Role category

Role description

Leader

Normal

A leader processes client requests and makes decisions. A leader maintains logs to ensure data consistency and recoverability.

Follower

Normal

A follower accepts and executes instructions from the leader. When the leader fails or becomes inaccessible, a follower can be elected to become the new leader.

Logger

Logger

Similar to a follower, a logger supports the majority consensus protocol but does not provide data services. When the leader fails or becomes inaccessible, loggers participate in the leader election. A logger may be elected as a temporary leader, but it does not provide data services. After the followers are updated and synchronized their status with the most recent data, the logger gives up leadership.

Learner

Normal

A learner passively receives state information from the system and does not participate in the leader election or decision-making process. Therefore, a learner produces minimal overhead on the system.

Primary and read-only instances

  1. The data nodes (DNs) of the primary instance have two normal replicas and one logger replica. The logger replica stores only logs and does not store data. Therefore, the three-replica configuration is similar to the traditional two-replica (primary/secondary) configuration.

  2. The DN of a read-only instance has one data replica, which assumes the learner role and asynchronously replicates data from the primary instance. It does not participate in the Paxos-based leader election and decision-making process. Therefore, issues that occur on the read-only instance do not affect the operation of the primary instance. This ensures fault isolation for the read-only instance.

High availability and disaster recovery

PolarDB-X implements the following Paxos-based replica policies on the DNs of the primary instance to ensure high availability and disaster recovery.

Deployment mode

Replica policy

Disaster recovery capability

Single zone

Three replicas (two normal replicas and one logger replica)

  • Can recover from a single-node failure.

  • Cannot recover from a data center failure.

Three zones

Three replicas (two normal replicas and one logger replica)

  • Can recover from a single-node failure.

  • Can recover from a data center failure.

  • Cannot recover from a city-level failure.

Three data centers across two regions

Five normal replicas

  • Can recover from a two-node failure.

  • Can recover from a data center failure.

  • Can recover from a city-level failure.

PolarDB-X implements the following replica policy on the DN of read-only instances to match the deployment mode of the primary instance:

Deployment mode of the primary instance

Replica policy of a read-only instance

Single zone

One replica, which can be in a different zone but must be in the same region as the primary instance.

Three zones

Three data centers across two regions

One replica, which can be in a different zone but must be in the same region as the primary data center of the primary instance.