PolarDB for PostgreSQL ensures zero data loss after any node failure by using X-Paxos based replication. X-Paxos consensus protocol was implemented by Alibaba and deployed in product systems supporting Alibaba major applications and platforms. X-Paxos achieves strong consistency cross replicas and high availability at replica failure. It allows cross-AZ and cross-DC network latency while maintaining high throughput and correctness.

PolarDB for PostgreSQL combined X-Paxos with PostgreSQL’s streaming replication function. X-Paxos is responsible for maintaining consistent replicas’ status, such their received and applied redo log positions, replicas’ role, and leader election, etc. PostgreSQL’s streaming replication offers functions of WAL’s transferring and receiving and persistency.

On leader node, a consensus service is deployed to negotiate the log synchronization positions with follower nodes. Those positions are used to determine the starting WAL records to be sent to followers. Transactions can commit only after majority nodes have received WAL records and they are persistent to disks, called reaching consensus. At the same time, any data related persistence operations (write IO) needs to wait for the corresponding WAL records reach consensus among replicas. For follower nodes, their recovery process applies a WAL record only when it reaches consensus. This can prevent any uncommitted data to become visible to users through follower nodes.

The consensus service maintains a consensus log. Its records store WAL entries’ locations. A leader node generates a consensus log entry based on the current local WAL position, and sends it to follower nodes. Followers receive the consensus log entry. They write it in local disks after ensuring that the WAL record corresponding to the consensus log entry is successfully persisted. A consensus log entry becomes persistent in majority nodes then the log entry reaches consensus. The leader node uses the WAL location recorded in the consensus log entry, which already reaches consensus, to determine the WAL location reaching consensus.

Follower nodes use X-Paxos state machine to manage streaming replication and log applying. WAL is pulled from leader node to follower nodes. When leadership changes, follower nodes use local received WAL position and send WAL requests to new leader node for any WAL after the position. When a follower is elected as a leader, it automatically exits from recovery and promotes itself as primary PostgreSQL instance, offering read and write service to clients

PolarDB for PostgreSQL supports multiple X-Paxos roles, such as leader, follower, and logger. The logger node differs from follower nodes in whether storing data and whether applying WAL to recovery data. Logger nodes only retain real-time WAL logs. It conducts streaming replication as followers but the received WAL logs are not played back. This means a logger node does not stores data or run recovery. Using logger nodes allows X-Paxos to achieve similar consensus across nodes with less storage cost paid.