RPO=0且RTO≤30秒是生产环境分片集群灾备的硬指标；MongoDB默认异步复制不满足RPO=0，需通过3节点跨机房副本集、w:majority写关注、writeConcernMajorityJournalDefault启用及config server独立3节点部署等措施保障。
灾备目标必须明确 RPO 和 RTO 数值
生产环境分片集群的灾备不是“能恢复就行”，而是要先锁定两个硬指标：RPO=0（零数据丢失）和 RTO≤30秒（故障后30秒内服务恢复）。MongoDB 副本集本身不保证 RPO=0，因为默认是异步复制；分片集群中 config server、shard、mongos 三类组件故障影响不同，必须分开设定目标。例如：config server 故障必须自动选举且元数据不丢，否则整个集群路由失效；shard 故障则依赖其内部副本集的同步机制是否开启 w:majority 写关注。
每个 shard 必须是 3 节点副本集，且跨机房部署
单节点 shard 或 2 节点副本集在灾备场景下等于裸奔。真实故障中常见的是整机房断电或网络隔离，如果三个副本都在同一机房，一次故障就可能同时击穿全部节点。正确做法是：
- 每个 shard 副本集包含 3 个节点，分别部署在 A 机房（主）、B 机房（从）、C 机房（从）
- 仲裁节点（arbiter）不能替代数据节点，它不存数据，无法参与故障后的数据恢复
- 设置
priority权重，确保主节点只在 A 机房选举产生；B/C 机房节点priority=0，仅用于数据同步和灾备读取 - 所有 shard 副本集启用
writeConcernMajorityJournalDefault: true，强制多数节点落盘日志才确认写入
config server 必须用 3 节点副本集，禁用单节点或嵌入式模式
config server 存的是整个分片集群的“大脑”——路由表、chunk 分布、分片键策略。一旦损坏或不可用，mongos 就无法知道数据在哪，整个集群对外失联。常见错误包括：
- 测试环境用
--configsvr启动单节点，上线后照搬，导致 config server 单点 - 把 config server 和某个 shard 共用同一台物理机，违反故障域隔离原则
- 未配置
replSet名称或初始化时未执行rs.initiate()，副本集状态长期为STARTUP2
生产环境必须用独立的 3 节点副本集，且与 shard 物理分离；建议使用专用小规格机器（如 4C8G），但必须保障磁盘 I/O 稳定性，避免因 journal 写入延迟拖慢整个集群元数据更新。
mongos 实例要部署多个，并接入统一负载均衡
mongos 是无状态的，但它挂了，客户端连接就会中断。很多人只起一个 mongos，以为“它不存数据就无所谓”，却忽略了 DNS 缓存、客户端连接池复用、以及应用重启前的冷启动延迟问题。实际操作建议：
- 至少部署 2 个 mongos 实例，分布在不同可用区
- 前端用 Nginx 或云厂商 SLB 做 TCP 层负载均衡（非 HTTP），监听 27017 端口
- 客户端连接字符串中不要写死单个 mongos 地址，而应使用负载均衡 VIP 或域名
- 定期检查
mongos进程存活、CPU 使用率、以及sh.status()中的 chunk 均衡状态，避免因长期未迁移导致某 shard 过载后响应变慢，被误判为故障
真正容易被忽略的是 config server 的备份节奏和验证机制——它不像数据节点那样有 mongodump 可随时导出，它的快照必须在副本集健康状态下通过 mongodump --uri="mongodb://cfg1:27019,cfg2:27019,cfg3:27019/?replicaSet=configRepl" 执行，且每次变更分片策略后都应触发一次增量校验。没做过真实恢复演练的灾备方案，只是纸面流程。
