How Alibaba Cloud RDS MySQL Three‑Node Enterprise Uses X‑Paxos for High Availability

Background and High‑Availability Challenges

Traditional master‑slave MySQL deployments rely on asynchronous or semi‑synchronous replication, both of which can suffer data loss or write‑performance degradation under failures or network issues. To achieve stronger guarantees, Alibaba Cloud RDS offers a three‑node enterprise edition that builds on extensive production experience.

X‑Paxos Consensus Protocol

The core of the three‑node edition is the proprietary X‑Paxos protocol, an extension of classic Paxos that adds automatic leader election, log synchronization, strong consistency, and online configuration changes.

Original Paxos defines three roles: Proposer, Accepter, and Learner. X‑Paxos expands this to four node types:

Proposer : initiates consensus proposals.

Accepter : votes on proposals to form a quorum.

Learner : a read‑only replica that does not participate in voting but replays committed logs.

Logger : a special follower that stores logs for quorum decisions and voting but never replays the state machine.

Additionally, a Follower acts as a disaster‑recovery node that collects leader logs and promotes a new leader when the current one fails.

The protocol persists two components: the log (state‑machine updates) and the state machine (actual business data).

Modified Commit Flow

In standard MySQL the commit sequence is flush → sync → commit. The three‑node edition changes the commit stage: all transactions entering the commit stage are placed into an asynchronous queue, then a quorum decision waits until the transaction log is replicated to a majority of nodes. Only after the quorum condition is satisfied does the transaction commit, ensuring strong consistency.

Election Mechanisms

1. Election Lease : X‑Paxos uses a unique proposer Multi‑Paxos scheme. Only one leader may serve at a time, preventing livelocks. Lease‑based election ensures that if the current leader becomes isolated, its lease expires and other nodes trigger a new election. The isolated leader detects lease loss via missed heartbeats and steps down, avoiding “dual‑leader” scenarios.

2. Weighted Election : Each node receives a weight; higher‑weight nodes are more likely to be chosen as leader during elections. This is useful in multi‑region deployments where a local node should be preferred to reduce cross‑region latency when the primary data center fails.