Paxos-Based Multi-Replica Architecture for PolarDB High Availability - PolarDB

Traditional active/standby high availability (HA) setups require manual intervention during failovers and cannot guarantee zero data loss. PolarDB-X Standard Edition replaces this model with a Paxos-based multi-replica architecture that delivers zero Recovery Point Objective (RPO) and automatic HA switching across all deployment modes.

Deployment modes

PolarDB-X supports three deployment modes to match different availability and disaster recovery requirements.

Deployment mode	Description
Single zone	Deploy all nodes in a single zone. Suitable for development, testing, or workloads tolerant of zone-level outages.
Three zones	Deploy nodes across three zones within a region. Suitable for production workloads requiring zone-level redundancy.
Three data centers across two regions	Deploy nodes across three data centers in two regions. Suitable for mission-critical systems requiring cross-region disaster recovery.

All three modes use Paxos consensus to guarantee zero RPO. Choose the mode based on your disaster recovery scope and network topology.

How it works

When a node fails in a multi-node database cluster, two problems arise: writes that were in flight may be lost, and the cluster must elect a new leader without human intervention. Paxos, a consensus algorithm, addresses both by requiring a majority of nodes to acknowledge each write before it commits, and by automating leader election through a heartbeat and timeout mechanism.

A PolarDB-X Standard Edition cluster operates in a single-leader model:

Leader node: The only node that accepts write operations. It adds consensus events to the binary log protocol before propagating log entries to followers.
Follower nodes: Participate in majority voting and synchronize data. Instead of using the traditional MySQL relay log, follower nodes use Paxos consensus logs, which integrate the binary log content of MySQL. The SQL thread replays these logs to data files.

Leader election: When follower nodes detect that the leader is unavailable, they elect a new leader automatically. The new leader does not serve traffic until the SQL thread finishes replaying all existing logs to data files, ensuring consistency before resuming writes.

Benefits

Benefit	How it works
Zero RPO	The majority-based synchronization mechanism ensures every committed write is acknowledged by a quorum of nodes before succeeding. No committed data is lost on failover.
Automatic HA	Follower nodes continuously monitor the leader via heartbeat. On failure, they elect a new leader without manual intervention, replacing the traditional active/standby HA model.
High performance	The single-leader write model delivers performance comparable to MySQL semi-sync replication, with the added guarantee of zero data loss.

Tip: To improve leader election efficiency during cross-data center failover, set higher ELECTION_WEIGHT values for replicas in the same data center to enhance their chances of winning the election.

Monitor replica status

Three system views let you inspect the Paxos cluster at different levels of detail.

Query global replica information

Returns the status of all replicas in the cluster. Only the leader node returns results; non-leader nodes return no rows.

SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_GLOBAL;

Example output:

+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
| SERVER_ID | IP_PORT          | MATCH_INDEX | NEXT_INDEX | ROLE     | HAS_VOTED | FORCE_SYNC | ELECTION_WEIGHT | LEARNER_SOURCE | APPLIED_INDEX | PIPELINING | SEND_APPLIED |
+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
|         1 | 10.0.3.244:14886 |           1 |          0 | Leader   | Yes       | No         |               5 |              0 |             0 | No         | No           |
|         2 | 10.0.3.245:14886 |           1 |          2 | Follower | Yes       | No         |               5 |              0 |             1 | Yes        | No           |
|         3 | 10.0.3.246:14886 |           1 |          2 | Follower | No        | No         |               5 |              0 |             1 | Yes        | No           |
+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
3 rows in set (0.00 sec)

Key columns:

Column	Description
`IP_PORT`	IP address and port of the replica
`ROLE`	Role of the replica: `Leader`, `Follower`, or `Learner`
`ELECTION_WEIGHT`	Election weight. Applicable to cross-data center disaster recovery scenarios. Set higher values for replicas in the same data center to enhance their chances of winning the election.
`MATCH_INDEX` / `NEXT_INDEX` / `APPLIED_INDEX`	Index of a consensus log

Query local node status

Returns the Paxos state of the local system.

SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_LOCAL\G

Example output:

*************************** 1. row ***************************
          SERVER_ID: 1
       CURRENT_TERM: 6
     CURRENT_LEADER: 10.0.3.244:14886
       COMMIT_INDEX: 1
      LAST_LOG_TERM: 6
     LAST_LOG_INDEX: 1
               ROLE: Leader
          VOTED_FOR: 1
   LAST_APPLY_INDEX: 0
SERVER_READY_FOR_RW: Yes
      INSTANCE_TYPE: Normal

Key columns:

Column	Description
`CURRENT_LEADER`	IP address and port of the current leader node
`ROLE`	Role of this node: `Leader`, `Follower`, or `Learner`
`SERVER_READY_FOR_RW`	Whether this node is ready to serve read/write traffic. During leader election, the new leader returns `No` until log replay is complete.
`INSTANCE_TYPE`	Type of the replica. Valid values: `Normal` and `Log`

Query replication health

Returns the synchronization status between the leader and each follower. Only the leader node returns results.

SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_HEALTH;

Example output:

+-----------+------------------+----------+-----------+---------------+-----------------+
| SERVER_ID | IP_PORT          | ROLE     | CONNECTED | LOG_DELAY_NUM | APPLY_DELAY_NUM |
+-----------+------------------+----------+-----------+---------------+-----------------+
|         1 | 10.0.3.244:14886 | Follower | YES       |             0 |              22 |
|         2 | 10.0.3.245:14886 | Leader   | YES       |             0 |               0 |
|         3 | 10.0.3.246:14886 | Follower | YES       |             0 |              11 |
+-----------+------------------+----------+-----------+---------------+-----------------+

Key columns:

Column	Description
`CONNECTED`	Whether the node is reachable and operating normally
`LOG_DELAY_NUM`	Latency of consensus log synchronization in Paxos, which is similar to the latency of relay log synchronization in MySQL
`APPLY_DELAY_NUM`	Replay delay of Paxos consensus logs on the follower node, which is similar to the replay delay of the SQL relay thread in MySQL