作为一款分布式数据库，平凯数据库天然具备多副本高可用能力。
数据以多副本方式分布在不同存储节点上，并通过 Raft 一致性协议保障副本之间的数据一致性。当部分节点发生故障时，只要集群仍然满足多数派要求，数据库就能够继续对外提供服务。
这意味着，单台服务器宕机、单块磁盘损坏或者少数存储节点异常，通常不会导致整个数据库停止运行。
既然一份数据已经保存了多个副本，为什么还需要再建设一套灾备集群？
因为多副本高可用解决的是一个平凯数据库集群内部的局部故障，而企业还必须考虑另一类风险：如果不可用的不是一台服务器，而是整个数据库集群，甚至整个生产机房怎么办？
本文介绍从集群内高可用、集群级容灾到历史数据恢复的平凯数据库的容灾能力。
三副本保护的是数据，也存在自己的故障边界
在平凯数据库中，数据会被划分并分布到多个 TiKV 节点上，每个数据分片通常保存多个副本。副本之间通过 Raft 协议保持一致，只有得到多数派确认，数据写入才能完成。
这种架构能够应对多种常见故障：
- 一台服务器突然宕机；
- 一块磁盘或者部分硬件损坏；
- 单个 TiKV 节点无法提供服务；
- 少数副本暂时不可用；
- 集群内部出现局部网络异常。
发生这些故障时，其他健康副本可以继续承担数据服务。故障节点恢复后，平凯数据库还可以重新调度并补齐副本，使集群恢复到正常状态。
这是分布式数据库相较传统单机数据库的重要优势：许多局部故障可以在集群内部被消化，不必立即恢复备份，也不必将业务切换到另一套数据库。
但是，多副本仍然有明确的保护边界。
三份数据即使部署在三台不同的服务器上，仍然可能属于同一个集群，共享相同的机房、网络、管理平台和运维体系。当故障超出集群内部的容错范围，多副本就不一定能够继续发挥作用。
例如：
- 生产机房整体断电或者网络中断；
- 数据中心基础设施发生严重故障；
- 多个关键组件同时不可用；
- 一次错误变更影响整个数据库集群；
- 集群因系统性软件或运维问题无法继续运行。
这时，问题已经不再是“能否找到另一个健康副本”，而是“是否存在另一个独立集群，可以接替生产集群继续运行”。
因此，平凯数据库的三副本高可用，并不等于完整的数据库灾备。
从节点高可用，走向集群级容灾
高可用和灾备的差异，本质上是故障范围不同。
平凯数据库集群内的多副本机制，关注的是部分节点发生故障后，当前集群能否继续运行。
灾备关注的则是，当整个生产集群或者生产机房无法继续运行时，业务能否切换到另外一套数据库集群。
如果把数据库比作一栋大楼，多副本高可用就像大楼内部的备用电源和冗余设备。某台设备损坏，其他设备可以立即补位。
灾备集群则是在另一处准备了一座具备独立运行能力的备用大楼。当原来的大楼整体无法使用时，企业仍然可以恢复运营。
对于核心交易、金融服务、运营商、能源、交通以及大型政企系统来说，只具备第一种能力通常是不够的。企业还需要突破单个集群和单个机房的故障边界，建立集群级的数据保护能力。
平凯数据库物理复制正是为这一目标而设计。
平凯数据库物理复制，不只是“再复制一份数据”
建设灾备系统，不能简单地理解为再部署一套平凯数据库。
真正的问题在于：生产集群的数据如何持续、完整、高效地进入灾备集群；复制中断后如何继续追赶；发生灾难时，灾备集群能否成为一套可接管业务的独立数据库。
平凯数据库物理复制从数据库存储层复制数据变化，在生产集群与灾备集群之间建立物理级复制关系。
两套集群拥有各自独立的 TiDB、PD 和 TiKV 等组件，可以部署在不同机房或者不同地域。生产集群继续承载正常业务，数据变化持续复制到灾备集群。
相比主要面向数据分发、异构同步和下游消费的逻辑复制，物理复制更加聚焦平凯数据库集群之间的数据保护与灾难恢复。
其价值主要体现在三个方面。
第一，突破单个集群的故障范围
生产集群和灾备集群彼此独立。即使生产集群整体不可用，灾备集群仍然具备独立运行并承载业务的基础。
平凯数据库的保护范围由节点级、组件级故障，进一步扩展到集群级和机房级灾难。
第二，面向大规模数据降低灾备建设复杂度
对于数据规模较大的核心系统，灾备方案不仅要考虑日常增量同步，还要考虑灾备集群初始化、复制链路中断后的数据追赶，以及长期运行中的稳定性。
物理复制直接面向平凯数据库集群之间的数据复制，减少在数据库之外拼装复杂同步链路的需要，使灾备关系更贴近数据库本身的数据组织方式。
第三，让灾备集群具备实际接管价值
灾备的目标不是“在另一个地方存有一份数据”，而是当生产集群不可用时，另一套平凯数据库能够按照既定流程接管业务。
企业可以围绕物理复制建立计划内切换、灾难切换和定期演练机制，把灾备集群从静态的数据副本变成业务连续性体系的一部分。
不过，物理复制解决的是集群级可用性问题，并不能替代所有数据保护措施。
有了物理复制，为什么仍然需要 BR 和 PITR？
物理复制会将生产集群的数据变化持续传递到灾备集群。
这对于保障数据连续性至关重要，但也意味着：如果生产环境执行了错误的数据操作，这些变化同样可能被复制到灾备端。例如：
- 管理员误删了一张业务表；
- 应用缺陷导致大量数据被错误更新；
- 错误脚本污染了生产数据；
- 攻击者获得权限并加密或破坏数据；
- 问题经过一段时间后才被业务发现。
这些情况下，切换到灾备集群并不能解决问题，因为灾备集群中可能已经包含同样的错误数据。
企业真正需要的是，把数据库恢复到错误发生之前的正确状态。
平凯数据库提供 BR 备份恢复和 PITR 时间点恢复能力。通过定期备份和持续保存日志，企业可以按照需要恢复完整数据，或者将数据恢复到指定历史时间点。
因此，物理复制与 BR、PITR 并不是替代关系：
- 物理复制主要解决生产集群整体不可用的问题；
- BR 和 PITR 主要解决数据已经被删除、污染或破坏的问题。
一个关注“数据库在哪里恢复运行”，另一个关注“恢复出来的数据是否正确”。
平凯数据库的三层数据保护体系
面对不同范围、不同性质的故障，平凯数据库可以通过三层能力构建完整的数据保护体系。
第一层：集群内故障，由多副本高可用解决
平凯数据库基于分布式架构和 Raft 多副本机制，在集群内部提供数据一致性和故障容错能力。
当服务器、磁盘或者少数数据库节点发生故障时，其他健康副本可以继续提供服务，避免局部故障直接演变为整个数据库不可用。
这一层解决的是：一个平凯数据库集群如何在部分组件故障时继续运行。
第二层：集群级、机房级灾难，由物理复制解决
平凯数据库物理复制在两个独立集群之间持续复制数据，使灾备集群可以部署到另一个机房或者地域。
当生产集群整体不可用时，企业可以按照预先设计的流程启用灾备集群，将数据库的保护范围从单个节点扩展到整个集群和数据中心。
这一层解决的是：当一个平凯数据库集群无法继续运行时，业务如何在另一个集群恢复。
第三层：误操作、勒索和历史数据恢复，由备份与 PITR 解决
平凯数据库 BR 和 PITR 提供独立于在线副本的历史恢复能力。
当错误操作或者恶意破坏已经传播到生产副本和灾备集群时，企业仍然可以通过备份和日志，将数据恢复到正确的历史时间点。
这一层解决的是：当所有在线数据都已经出现问题时，如何找回正确的数据。
由此，平凯数据库形成了边界清晰、相互补充的三层数据保护体系：
- 集群内故障，由多副本高可用解决；
- 集群级、机房级灾难，由物理复制解决；
- 误操作、勒索和历史数据恢复，由备份与 PITR 解决。
总结
三副本回答的是“一个集群能不能扛住局部故障”，物理复制回答的是“一个集群消失后业务在哪里恢复”，BR 和 PITR 回答的是“在线数据都出现问题后，如何回到正确状态”。
对于关键业务而言，真正可靠的数据库架构不是简单增加副本数量，而是根据风险范围建立分层保护：既能处理一台服务器的故障，也能应对整个集群、整个机房突然不可用，还能在数据被错误修改后回到正确的历史时刻。