Bug：mongodb机房迁移导致gss宕机

一、背景

1. 环境信息：生产环境、MongoDB 分片集群、版本 7.0.14
2. 集群架构：2 个 Mongos 路由节点、3 个 Shard 分片、单个 Shard 为 3 节点副本集
3. 业务关联：供 HIS-GSS 核心服务使用
4. 操作目的：对 单个Shard分片 执行副本集扩容，从3节点调整为4节点（新增11机房节点），为后续机房迁移做准备。
5. 关键配置：副本集写入策略 w:majority（大多数确认策略）

二、事故表现

1. 目标 Shard 分片 全量写入阻塞、数据库连接 Hang 死
2. 上游 HIS-GSS 服务请求大量堆积，资源耗尽
3. GSS 服务进程宕机重启，核心业务受影响
4. 集群触发告警，人工介入恢复

三、根本原因

DBA 对目标 3 节点副本集 Shard 扩容至 4 节点时，先使用凌晨冷备份初始化新节点，因增量同步速度过慢，直接对运行中的老从节点执行物理数据文件拷贝，触发 MongoDB 全局读锁，导致该节点完全停止读写。

副本集 4 节点仅 2 个可用，不满足w:majority（需 3 节点确认），最终 Shard 分片整体不可写。

进而导致后续一系列故障表现。

四、时间线 & 对应表现

1. 2026年4月17日13:00：执行 Shard 分片扩容，新节点使用凌晨冷备份启动

   状态：新节点正常追赶增量数据，同步速率较慢

2. 2026年4月17日16:13：DBA手动执行物理拷贝：从在线老从节点复制数据文件至新节点

   触发源节点 全局锁，节点卡死、无读写、无副本集心跳

3. 2026年4月17日16:13：副本集状态异常

   4 节点中仅主节点 +1 个从节点正常，被锁节点 + 新节点异常

4. 2026年4月17日16:13：写入策略不满足

   4 节点majority要求 3 台确认，仅 2 台可用，所有写入永久阻塞

5. 2026年4月17日16:17：业务雪崩

   HIS-GSS 请求堆积、线程/连接耗尽，GSS 宕机重启。前几次还拉起失败了，后面重试了几次才拉取成功的。

6. 2026年4月17日16:20：DBA 停止手动拷贝操作

7. 2026年4月17日16:21：数据库恢复正常，GSS 拉起成功，业务恢复正常。

8. 【占位】

五、技术反思

1. 高危违规操作：在 MongoDB 7.0.14 在线运行节点上，直接物理拷贝数据文件，触发全局锁导致节点不可用
2. 架构特性未评估：3 节点副本集扩容为 4 节点后，w:majority阈值从 2 提升至 3，集群容错能力降低，未提前识别风险
3. 操作不规范：放弃官方支持的安全同步方案，采用暴力方式加速同步
4. 分片集群风险：单 Shard 分片不可用，直接导致依赖该分片的核心业务瘫痪

六、后续改进

1. 严禁高危操作：生产环境禁止直接cp/scp在线运行的 MongoDB 数据文件，杜绝全局锁风险
2. 标准化扩容流程
   • 优先使用 MongoDB 7.0.14 官方fileCopyBased物理同步模式
   • 备选方案：冷备份/磁盘快照初始化 → 新节点追增量 → 加入副本集
3. 扩容前置评估：副本集节点数变更必须校验w:majority阈值和集群容错能力
4. 变更监控与灰度：扩容过程全程监控节点锁状态、副本集健康度，新节点就绪后再正式接入
5. 分片集群防护：完善单 Shard 故障的业务熔断/限流策略，避免单点故障传导至上游核心服务

七、思考

• 生产变更安全优先于效率，加速同步必须使用官方/快照方案，禁止暴力操作
• MongoDB 分片集群中，单 Shard 分片的可用性直接决定业务可用性，变更需最高级管控
• 3 节点→4 节点副本集扩容会降低临时容错率，是高风险变更，需严格执行 SOP

八、后续可深入了解

1. MongoDB 7.0.x 分片集群+副本集高可用设计
2. w:majority 计算规则与分片集群可用性影响
3. MongoDB 7.0 官方fileCopyBased初始同步最佳实践
4. 单可用区分片集群的容灾与变更风险控制
5. Mongos 路由、Shard 分片故障传导机制与业务防护方案