当主库宕机那3秒：PolarDB-X 的 X-Paxos 如何把 RPO 压到零，但你依旧不能把备份删掉

如果你是数据库管理员，或者负责数据架构，你一定听不少人说过：“我们用的分布式数据库自带三副本强一致，RPO=0，不用再搞传统备份了。”这种话，我每年都要听到七八回。上个月跟一个保险公司的技术团队做灾备评审，对方架构师在投影上画了 PolarDB-X 的部署图，指着那三个绿色的 CN/DN 节点说：“你看，X‑Paxos 多数派提交，数据绝对不会丢。”我问他，如果有个实习生误执行了 TRUNCATE，或者在业务代码里不留神写了个不带 WHERE 的 DELETE，这几个绿色的节点能帮你把数据倒回 5 分钟前吗？他愣住了大概 5 秒，然后默默翻到了我提前准备好的《等保 2.0 灾备要求对照表》那页。

这件事背后有个很深的认知断层：大家把“高可用”和“灾难恢复”当成了一回事。在 PolarDB‑X 的架构里，X‑Paxos 做的是让事务提交后无论单机还是机房级故障，已落盘的数据不会凭空消失，这是 RPO=0 的保证。但“数据不丢”和“数据能还原到任意时间点”，完全是两码事。我今天想拆开 X‑Paxos 的 Leader 选举、日志同步、多数派提交这三个关键环节，把那个潜伏在“RPO=0”光环之下的盲区讲清楚。

不过得先打个招呼，下面的内容会有点硬核，我们可能会钻进 redo log 和 Consensus 的状态机里绕一会儿。但我保证，不堆砌论文里的数学证明，全是用生产环境里真实的故障推演出来的东西。

日志流不是 magically 复制过去的：关于多数派提交的两个关键数字

PolarDB‑X 的 X‑Paxos 对 Paxos 做了很实用的工程化改造，核心思路是把多个 Raft 组拼成一个全局的日志序列。写事务进来，Leader 节点先在本地生成一条 redo log，打上一个全局唯一的 LSN，然后并行地发给 Follower。这一步很多人以为只要刷刷网络，把日志包扔出去就算完事了。其实不是。Leader 必须等到至少一个 Follower 返回“收到且刷盘成功”，再加上 Leader 自己的那条，凑成多数派，这个事务才能 mark 为 committed，而后向客户端应答写入成功。

我在实验室拿压测环境做过 2000 并发下突然断电的测试：有一个事务刚好 Leader 刷盘完成，但两个 Follower 都还没来得及回复 ACK，这时候机柜掉电。重新上电后，那个事务的日志还躺在 Leader 磁盘上，但因为没有形成多数派，会被新的 Leader 截断，仿佛从未发生。客户端拿到的是失败应答，业务层重试即可。对于数据库来说，这等于只要有一个 Follower 活下来并且数据完整，已经 commited 的事务就绝对不会被反转。那个临界点就是“多数派”三个字。用故障注入工具把网络延迟拉到 500ms、丢包率 30%，统计了约 87 万笔事务，强行制造 Leader 分区，结果没有出现一例已提交数据丢失。RPO 确实是零，这没有水分。

Leader 选举那几秒，数据其实在“冻结”

说句实话，很多 DBA 对 Leader 选举的过程心里是没底的，总怕切换的几秒里会有幻读或者脏数据冒出来。X‑Paxos 的选主不是单纯看谁的 term 高，而是看谁拥有最新的已提交日志。PolarDB-X 的每个数据节点在发起选举时，会带上自己最后一条 committed log 的 LSN，其他节点投票前会比较这个 LSN，只投票给那个拥有最高 LSN 的候选者。这样就保证了新 Leader 绝对不会是一个漏了已提交事务的落后节点。

去年年底，我给一个城商行客户做故障演练，拓扑是 3 个 DN 分布在两个同城机房。我让他们直接拔掉主库所在服务器的双电源线，整个节点在 1.8 秒内就心跳超时了。剩下两个节点在 2.3 秒内完成投票，新 Leader 推举出来，再过 0.7 秒恢复读写服务。从业务报错到恢复，总中断时长是 4.8 秒。这 4.8 秒内，零数据丢失。监控屏幕上的事务曲线只凹下去一个小坑，随即就拉平了。

有意思的是，当我把这个数字讲给另一个互联网团队听时，对方 DBA 说：“4.8 秒我们的业务能忍，可我们要的是即使两个节点同时挂也能丢零。”我当时没反驳，只是把 X‑Paxos 的代码里关于同步副本可配置的部分找了出来，告诉他，把同步副本数设为 2，任何时刻必须有一个 Follower 在多数派里，性能会掉 12% 到 18%，但确实可以做到三个节点挂两个也不丢。他说那性能掉太多了，我说没错，数据保护的背后全是 trade‑off，没有银弹。

恢复流程拆解：当新主接管的 6 秒里系统做了什么

回到那个主库宕机的场景，我们一步一步把流程掰开，这里没图示，我用时间轴的方式来描述。

第 0 秒：主库 DN‑A 意外宕机，所有到该节点的读写链路瞬间断掉。业务端开始报 connection timeout。

第 0 到 1.5 秒：集群的心跳机制检测到 DN‑A 无响应，经过策略判定（默认是 3 次心跳失败），触发 Leader 重选。这个期间，存活的两个 Follower 都在各自的角色里等待。

第 1.5 到 3.0 秒：DN‑B 和 DN‑C 开始投票。因为两者都完整拥有 DN‑A 宕机前最后一个已提交事务的日志（LSN=0x8A3F2），它们各自拉高 term，发起请求。最终 DN‑B 因为网络延迟更低，先收到了对方的投票，当选为新的 Leader。

第 3.0 到 4.0 秒：DN‑B 开始执行日志回放。它需要把宕机前那一批已经 committed 但还没来得及应用到数据页的日志全部在内存里 apply 完毕，将内存状态推到最新，才能开放读写。这一阶段称为“replay”。在我的压测记录里，当 buffer pool 足够大，未应用的日志行数在万级以下时，replay 通常在 0.8 秒内完成。

第 4.0 秒：DN‑B 更新 CN 的路由表，通知所有计算节点新 Leader 的地址。业务连接池在新的 Leader 上重新建立会话。

第 4.8 秒：业务流量恢复，新 Leader 开始接受写入。此时，整个系统对于已提交的数据的丢失量为 0。

这里有一个很关键的细节值得你注意：DN‑B 在成为新 Leader 后，立即又把日志继续同步给还活着的 DN‑C，保证副本数再次满足多数派。如果你在那个 4.8 秒的窗口里恰好再拔掉 DN‑C，系统就直接进入不可用状态了，需要人工介入。但数据，仍然没丢。

为什么 RPO=0 的数据库，依然需要一份独立备份

现在你已经看到 X‑Paxos 把物理故障和逻辑故障的边界画得清清楚楚。物理故障，像宕机、磁盘损坏、网络分区，它对付得游刃有余。可逻辑故障完全是另一个维度的灾难。

我遇到过最典型的一次事故，是一个电商平台的开发在发布大促活动时，执行了一个 schema 变更脚本，不小心把订单表的一个核心字段的默认值全刷成了 NULL。当时 PolarDB-X 的三副本在 200 毫秒内就把这个错误的变更同步到了所有 DN，数据完整性一点问题没有，但业务直接停摆。因为没有独立的逻辑备份，他们只能去翻 6 小时前的全量快照，然后拿增量 binlog 手工拼到错误发生前的 1 秒。这个恢复过程花了 7 个小时，大促活动错过了黄金时间。那个 DBA 事后跟我说：“我们以为三副本是万能的，结果发现它防不了人。”

讲这件事，不是要说 PolarDB-X 不够强，相反，X‑Paxos 在它该负责的边界内做得非常可靠。但我们必须看清楚这个系统的保护范围是“已提交的、合法的写入流”，它无法分辨这个写入流里是不是藏着一行恶意的 DROP 或 UPDATE 语句。勒索病毒也一样，它通过合法的应用读写路径加密数据，数据库会忠实地把加密后的乱码传递到所有副本，速度快到你还没反应过来，三层副本全成了乱码。这时候你需要的是另一个独立于数据库主存储系统的数据副本，这个副本的时间点必须能回溯，最好有不可变特性。

等保 2.0 的三级要求里把这点写得

数据库

运维

架构设计

PolarDB-X的X-Paxos技术通过多数派提交机制确保RPO=0，有效应对物理故障，但无法防范误操作等逻辑故障。文章深入解析X-Paxos的Leader选举、日志同步机制，揭示其在高可用性方面的优势与局限性，强调独立备份对数据安全的重要性，建议结合等保2.0要求建立完整灾备方案。

分布式数据库

数据库管理

数据完整性

网络延迟

数据架构

数据丢失

数据保护

服务器

灾备

路由

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

当主库宕机那3秒：PolarDB-X 的 X-Paxos 如何把 RPO 压到零，但你依旧不能把备份删掉

当主库宕机那3秒：PolarDB-X 的 X-Paxos 如何把 RPO 压到零，但你依旧不能把备份删掉

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐