前言

DPC 分布式集群经常应用在同城双中心灾备建设，依靠多副本机制保障数据一致性和业务容错能力。运维人员需要理解集群组件角色、副本选举规则、双中心部署带来的业务约束，才能做好灾备设计和日常运维。本文站在使用者视角，介绍 DPC 同城双中心的业务架构模型、组件角色、部署约束，不涉及内部内核实现。

1 DPC 集群核心组件概念

BP 实例是 DPC 对外提供 SQL 服务的业务单元，多个 BP 组成复制副本组。

• 副本区分主副本、从副本，写操作在主副本执行，数据日志同步至从副本；
• 副本组遵循多数派规则：副本组存活节点超过半数，才可以选出主副本，对外提供读写服务。

2 同城双中心部署业务模型

同城双中心分为主中心、灾备中心，副本跨两个机房部署：

1. 主中心 BP 副本承担日常业务读写；灾备中心副本承担灾备备份；
2. 跨机房日志同步保证多副本数据一致。

部署约束：当灾备中心全部节点故障，需要评估主中心剩余副本数量是否满足多数派。如果不满足多数派条件，副本组无法选出主库，业务会整体中断。在做灾备方案设计时，需要提前评估该风险。

3 副本上下线的业务表现

集群维护副本成员状态信息，用于识别集群内有效实例：

1. 实例正常有序下线，集群会自动更新副本成员信息；
2. 如果灾备中心整体断电属于异常宕机，集群来不及更新副本成员记录，会残留旧副本信息。
   当灾备节点恢复启动，由于本地残留旧的成员信息，实例不会自动重新加入集群，需要人工介入清理旧记录，重新添加实例完成副本重建。

该为集群灾备场景下的业务行为，不是程序缺陷，需要纳入运维流程。

4 DEM 运维平台定位

DEM 为集群运维监控平台，只做状态采集展示，不参与业务数据读写，用于集中观测 BP 实例状态、副本存活、同步延迟等信息。部署依赖 JDK 环境，容易出现 JDK 环境变量路径不匹配的部署问题。

5 灾备架构实践启示

1. 设计同城双中心方案时，提前核算副本多数派数量，评估灾备整体故障后的业务连续性；
2. 灾备故障恢复没有完全自动化，需要人工清理旧副本记录、重新添加实例；
3. DEM 作为运维观测工具建议常态化部署，提前发现副本离线、同步延迟隐患；
4. 定期开展灾备演练，熟悉降级、恢复操作流程。

小结

DPC 同城双中心依靠多副本多数派实现高可用，在保障数据一致性的同时，存在对应的部署和运维约束。运维人员理解业务层面的行为特点，才能合理设计灾备方案，制定故障处置预案。