1. 课程导入与故障演练认知
MongoDB 在生产环境中承担着核心业务数据的持久化职责，一旦出现主节点宕机、副本集选举异常、分片集群路由失效、磁盘写满或误删集合等问题，业务侧往往在数秒内就能感知到。很多团队并不缺少监控告警，真正缺少的是在故障真实发生之前，已经完整演练过一遍“发现—判断—处置—验证”的全过程。本课程围绕“生产故障演练与恢复”展开，目标不是讲一堆 MongoDB 命令，而是让读者具备在压力下做出正确处置决策的能力。
一、为什么要做故障演练
故障演练的本质，是把“未知的应急能力”转化为“已知的、可复现的处置流程”。它至少带来四方面价值：
- 验证恢复手段是否真的可用：备份文件能否恢复、oplog 是否足够回滚、仲裁节点是否生效，这些只有实际演练才能确认，纸面预案往往存在盲区。
- 量化 RTO 与 RPO：RTO（恢复时间目标）和 RPO（恢复点目标）是业务连续性的核心指标。演练能给出真实数据，例如副本集主节点故障切换实测约 12 秒完成，而误删集合从备份恢复可能耗时 40 分钟。
- 暴露架构与配置缺陷：例如写关注（writeConcern）设置为
w:1时，主节点宕机可能丢失最近写入；读关注（readConcern）配置不当会导致读到回滚数据。 - 训练团队协作与决策：故障现场最怕的不是技术难，而是没人拍板。演练让值班、DBA、研发、业务方形成固定的沟通与决策路径。
演练不是“制造事故”，而是在受控条件下主动暴露问题。核心原则是：可控、可回退、有观测、有记录。任何演练都必须提前明确影响范围、回退方案和终止条件。
二、故障演练的核心原则
生产环境做演练，第一条红线是不能把演练变成真实事故。因此需要遵循以下原则：
- 影响可控：优先在预发或影子环境演练；必须在生产演练时，选择业务低峰期，并限制影响范围（如只针对一个次要分片或一个从节点）。
- 可回退：每一步操作都要有明确的回退动作。例如手动
rs.stepDown()触发切换后，若新主节点异常，应能快速回切或重启原主节点。 - 可观测：演练期间必须打开关键监控，包括副本集状态、oplog 窗口、连接数、慢查询、磁盘使用率，以及业务侧的错误率与延迟。
- 有记录：记录时间线、执行命令、观察到的指标变化、实际恢复耗时，形成可复盘的演练报告。
- 有边界：明确“不做什么”。例如不在业务高峰期做全量恢复，不在没有备份校验的情况下删除数据。
三、课程整体框架
本课程共 30 章，按照“认知—准备—演练—恢复—复盘”的递进逻辑组织，覆盖 MongoDB 生产环境中最常见、最危险的故障类型。整体结构可以概括为五个阶段：
- 认知与准备阶段：建立故障演练认知，梳理 MongoDB 高可用架构、副本集与分片集群的关键机制，明确演练范围与风险控制。
- 单点与副本集故障演练：主节点宕机、从节点延迟、选举异常、仲裁节点失效、oplog 窗口不足等。
- 分片集群故障演练：mongos 路由异常、config server 不可用、分片均衡阻塞、chunk 迁移失败。
- 数据层故障与恢复：误删集合、误更新、磁盘写满、备份恢复、时间点恢复（PITR）。
- 复盘与体系化：演练报告、改进项跟踪、预案迭代、常态化演练机制。
下图展示了本课程从“演练认知”到“恢复验证”的整体关系，以及各阶段对应的核心对象与输出物。它不是简单的章节列表，而是把故障演练中输入、处置动作、观测信号与结果判断之间的依赖关系呈现出来，便于读者建立全局视角。
四、从“知道”到“做到”
很多团队的问题不是不知道 MongoDB 有副本集，而是不知道主节点宕机后业务到底会中断多久、数据会不会丢、谁该在几分钟内做什么。本课程后续每一章都会围绕一个具体的故障场景，给出可执行的演练步骤、关键命令、观测指标和判断依据。例如在副本集主节点故障演练中，我们会实际执行：
// 查看当前副本集状态
rs.status()
// 手动触发主节点降级，模拟主节点故障
rs.stepDown(60)
// 观察选举过程与新的 PRIMARY
db.hello()
演练时重点观察：rs.stepDown() 执行后，原主节点是否在预期时间内降级为 SECONDARY，新主节点是否在 10～15 秒内产生，业务写入是否出现短暂失败，以及失败后是否自动重试成功。这些观察结果，才是判断“高可用是否真的高可用”的依据。
演练前必须确认：备份可用、oplog 窗口足够、监控正常、回退方案明确。任何一项缺失，都应先补齐再演练，否则演练本身就可能演变成事故。