An architect’s breakdown: quorum DR, split-brain, leases — and why “wait for the standby” isn’t the same as “survive minority failures.”
Takeaway: Paxos isn’t magic optimism. It’s a rule for turning messy partial failures into one durable story about what happened.
OceanBase applies this idea to durability. Data is replicated across multiple copies called replicas. Every database change first becomes redo / commit log entries. Those entries must be durably recorded on a majority of replicas — including the leader — before the transaction can return “commit success” to the client. So if a single machine loses a disk — or even the machine hosting the leader dies — as long as a majority of replicas is still reachable, your change has already been voted in and persisted on more than one machine. That is the engineering reason OceanBase can target RPO = 0 in many disaster-tolerance setups: reliability is not “this one box is special,” but “the quorum is the source of truth.”
RPO (Recovery Point Objective): the maximum acceptable amount of data loss after a failure — here, the design aims for zero committed data loss for the covered failure modes.
One clarification matters: replicas are not voting on “every tiny row change” as an isolated Paxos instance. In OceanBase, consensus operates at the log stream layer. A log stream is an internal abstraction that merges ordered log records for multiple partitions (shards of data). Batching many partition updates into one ordered stream lets a single Multi-Paxos interaction synchronize multiple partitions at once — less chatter on the network, better end-to-end efficiency.
High availability:
Cross-cloud active-active architecture:
Designing HA systems? What trade-offs are you making between RPO and availability? Drop your lessons below.
👏 Clap · 🔔 Follow for more database engineering deep dives
SOCIAL SHARE CARD GENERATOR