MongoDB分片集群Pod重启后无法加入如何修复

Pod重启后无法加入MongoDB分片集群，根本原因是重启后的mongod无法连接或通过配置服务器副本集（CSRS）校验：需检查CSRS连通性、--configdb配置准确性、CSRS健康状态、shards元数据一致性、DNS/TLS有效性及资源限制导致的探针误杀。

Pod 重启后无法加入 MongoDB 分片集群，通常不是单纯“重启失败”，而是节点在重启过程中未能重新同步元数据、丢失配置上下文，或被集群判定为不可信成员。核心问题在于：分片集群的 mongod 实例重启后，必须能正确连接配置服务器副本集（CSRS）、拉取最新分片路由信息，并完成自身状态校验——任一环节卡住，就会表现为“不在线”“未加入”或“状态为 STARTUP/RECOVERING 长期不变化”。

检查 mongod 启动日志里是否报 CSRS 连接失败

这是最常见原因。重启后的 mongod 必须能连上配置服务器副本集才能获取分片元数据。如果连接超时或认证失败，它会卡在 STARTUP2 状态，永远不进入 SECONDARY 或 PRIMARY。

1. 用 kubectl logs <pod-name> 查看日志，重点搜 Failed to connect to config server、could not find host in config server replica set、auth failed
2. 确认 Pod 内的 mongod 启动参数中 --configdb 指向的是配置服务器副本集名称 + 成员地址，例如 configReplSet/10.244.1.5:27019,10.244.2.6:27019,10.244.3.7:27019，而不是单个 IP
3. 检查 ConfigMap 中该字段是否被硬编码成旧地址，或 DNS 解析失效（比如 Kubernetes Service 名称变更但没更新）
4. 若使用 TLS，确认 --sslCAFile、--sslPEMKeyFile 路径存在且权限正确，证书未过期（2026 年多数集群已启用 TLS）

确认配置服务器副本集是否健康且主节点可写

即使 mongod 能连上 CSRS，如果 CSRS 自身不可用或处于只读状态（如主节点宕机且未成功选举），新节点就无法拉取元数据，也不会被集群接纳。

1. 进任意一个配置服务器 Pod，执行 mongo --eval "rs.status()"，检查 members[n].stateStr 是否有 PRIMARY，且 ok: 1
2. 若状态为 SECONDARY 但 electionId 为空，或 health: 0，说明该节点未同步完成，不能参与投票
3. 若整个 CSRS 卡在 STARTUP 或 RECOVERING，需先恢复 CSRS——这比修复分片节点更紧急，否则所有新节点都会失败
4. 注意：CSRS 不可用时，分片节点仍可读写本地数据，但无法做 chunk 迁移、split 或接收新路由规则

验证分片节点是否被配置服务器“记住”

MongoDB 分片集群靠配置服务器持久化每个分片的 shard 条目。如果重启后该节点的 hostname/IP 变了，而配置服务器里还存着旧地址，就会拒绝其加入。

1. 在配置服务器上运行：mongo --eval "db.shards.find().pretty()"，检查对应分片的 host 字段是否匹配当前 Pod 的实际地址（如 shard01/10.244.4.8:27018）
2. 若地址不符，不能直接改 db.shards.updateOne() —— 这会破坏一致性；正确做法是先用 sh.removeShard("shardName") 移除旧条目，再用 sh.addShard("shardName/host:port") 重新添加
3. 注意：执行 removeShard 前必须确保该分片无活跃 chunk 迁移，否则会阻塞；可用 sh.status() 观察 draining: true 是否完成
4. 如果 Pod 使用 headless Service，确认其 DNS 记录（如 shard01-0.shard01-headless.default.svc.cluster.local）在重启后解析结果未变

检查 Pod 是否因资源不足或探针误判反复重启

表面上是“无法加入”，实则是容器启动后几秒内就被 kubelet 杀掉，根本没机会完成初始化流程。

1. 运行 kubectl describe pod <pod-name>，查看 Events 区域是否有 OOMKilled、CrashLoopBackOff 或 Liveness probe failed
2. mongod 启动慢（尤其首次加载大量数据或开启 journal），若 livenessProbe.initialDelaySeconds 小于 60 秒，很可能在它连上 CSRS 前就被 kill
3. 内存限制设得太低（如 limits.memory: 512Mi）会导致 mmapv1 引擎频繁 OOM，WiredTiger 则可能因 cache 太小直接拒绝启动
4. 临时绕过探针调试：把 livenessProbe 和 readinessProbe 全部注释掉，观察 Pod 是否能稳定运行并进入 SECONDARY 状态

真正卡住的地方往往不在分片节点本身，而在它和配置服务器之间的信任链断点——可能是 DNS、TLS、CSRS 状态、或配置服务器里残留的旧地址。修之前先确认：这个 Pod 是“连不上”，还是“连上了但被拒之门外”，或是“根本没机会连”。