MongoDB分片集群的故障处理比单机或副本集要复杂一些，原因在于它涉及mongos、config server、shard三层组件，任何一个环节出问题都可能导致读写异常。很多故障表面上看是查询变慢或者连接超时，实际根源可能藏在配置服务器的选举状态、chunk迁移的锁等待、甚至某个分片节点的磁盘空间里。下面把常见的几类问题拆开来讲，每部分都给出判断依据和处理方式。
一、分片集群故障高发点与通用排查思路
分片集群的组件分工明确：mongos负责路由，config server保存元数据，shard存储实际数据。故障高发点也集中在这些组件的连接与状态同步上。mongos本身无状态，但如果配置服务器地址写错或config server宕机，mongos启动时就会报错，运行中的mongos也会因为元数据刷新失败而拒绝新的查询。shard层面最常见的故障是复制集主节点切换导致写中断，以及磁盘写满导致节点进入RECOVERING状态。
通用的排查思路是先确认集群整体是否可访问，再逐步缩小范围。登录任意mongos执行sh.status()可以查看分片状态和chunk分布，执行db.adminCommand({listShards:1})可以列出所有分片及其健康情况。如果连mongos都连不上，就需要检查mongos进程日志和config server连接。对于shard故障，优先查看各shard复制集的状态，使用rs.status()检查是否有节点处于异常状态。日志文件通常位于mongod或mongos的启动参数指定的logpath，查看最近的错误关键字能快速定位问题。
排查过程中有个容易被忽略的点：mongos会把配置服务器返回的元数据缓存在内存中，如果配置服务器发生主节点切换，mongos可能还会短暂指向旧主节点，导致一段时间的路由失败。此时可以尝试重启mongos，或者等待其内部重连机制生效。不要一上来就重建集群，绝大部分问题可以靠调整连接、清理锁或重启单个进程解决。
二、配置服务器与mongos进程的典型故障
配置服务器以副本集形式运行，存储所有分片和chunk的元数据。它最常见的故障是多数派节点不可用，导致配置副本集无法选举出主节点，整个集群的元数据操作都会阻塞。例如三个配置服务器中有两个同时宕机，剩余一个节点会进入SECONDARY状态，无法处理写请求。此时mongos还能读旧缓存，但任何需要元数据变更的操作（如chunk迁移、分片新增）都会失败。
处理配置服务器多数派丢失的步骤是：先恢复至少两个配置服务器节点，确保它们能相互通信并重新选举。如果原主节点数据损坏，可以从备份恢复config数据库，或者用一个健康的从节点强制提升为主。启动配置服务器时需要使用--configsvr参数，并且副本集名称要和mongos启动参数--configdb中指定的一致。如果配置服务器地址发生变化，需要重启所有mongos实例并更新--configdb参数。
mongos进程本身崩溃的原因通常是连接数过高或者内存不足。mongos默认的连接池大小可能不适合高并发场景，可以通过启动参数--taskExecutorPoolSize调整工作线程数量，通过--maxConns限制最大连接数。如果mongos频繁OOM，需要检查是否有大量慢查询堆积，或者客户端连接没有及时释放。可以在mongos上执行db.currentOp()查看正在执行的操作，找出长时间未完成的查询并终止。
# 检查mongos与配置服务器的连接状态
mongosh --host mongos_host:27017 --eval "db.adminCommand({listShards:1})"
# 查看当前活跃操作，过滤超过5秒的查询
db.currentOp({"active" : true, "secs_running" : {"$gt" : 5}})
此外，mongos启动时会校验配置服务器副本集名称，如果配置服务器曾经重建但名称改变，mongos会拒绝启动。这时需要明确指定新的副本集名称，并确保配置服务器节点数与副本集配置一致。排查时注意观察mongos日志中的config server相关错误，通常会直接指出连接失败的原因。
三、chunk迁移卡住与均衡器故障
chunk迁移是分片集群动态调整数据分布的核心机制，但迁移过程很容易卡住。常见原因包括源分片或目标分片磁盘空间不足、网络抖动导致迁移中断、迁移过程中源分片发生主节点切换、以及残留的迁移锁未释放。当chunk迁移卡住时，sh.status(true)会显示某个chunk长时间处于MIGRATING状态，或者db.locks.find()中能查到对应的锁记录。
处理迁移卡住的第一步是确认卡住的具体chunk范围，然后手动清理残留锁。登录config数据库执行db.locks.remove({"_id" : "databasename.collectionname"})可以删除对应的迁移锁，但删除前最好确认没有正在进行的迁移操作。清理锁之后，可以重新发起手动迁移，使用sh.moveChunk("db.collection", {shardKey: value}, "targetShard")指定目标分片。如果手动迁移仍然失败，需要检查目标分片是否有足够的磁盘空间，以及源分片是否处于健康状态。
均衡器本身也可能因为配置服务器不可用或者迁移失败而停止工作。通过sh.getBalancerState()可以查看均衡器是否开启，通过sh.setBalancerState(false)可以临时关闭均衡器，避免在故障处理期间继续触发迁移。在业务高峰期，建议设置均衡窗口，使用sh.setBalancerWindow()限制均衡器只在低峰期运行。如果某个集合的chunk分布极不均匀，手动moveChunk比等待均衡器自动调整更直接。
// 查看chunk迁移状态
sh.status(true)
// 清理残留迁移锁
use config
db.locks.remove({"_id" : "mydb.mycollection"})
// 手动迁移一个chunk
sh.moveChunk("mydb.mycollection", {userId: 1000}, "shard0002")
还有一个容易忽略的场景：chunk分裂失败会导致单个chunk过大，影响迁移和查询效率。如果发现某个chunk的文档数远超默认的64MB限制，可以手动执行sh.splitAt()或sh.splitFind()进行分裂。分裂操作同样需要锁，如果锁被占用，需要先清理锁再执行分裂。
四、读写性能下降与连接池问题
分片集群的读写性能下降不一定源于硬件瓶颈，很多时候和分片键的选择直接相关。如果分片键的基数过低或者查询条件不包含分片键，mongos需要把请求广播到所有分片，这就是常说的scatter-gather查询，会显著放大延迟。例如在一个按用户ID分片的集合上，按时间范围查询订单，如果时间字段不是分片键，mongos必须查询所有分片再合并结果。优化手段包括设计复合分片键、使用范围查询时尽量包含分片键前缀，或者对高频查询字段建立全局二级索引。
连接池耗尽也是常见问题。客户端连接mongos时，mongos会维持到后端分片的连接池，默认大小可能不足以支撑突发流量。可以在mongos启动时通过--taskExecutorPoolSize调大工作线程池，同时客户端侧也要配置合理的连接池上限。如果连接数过高，可以在mongos上执行db.serverStatus().connections查看当前连接数和可用连接数，必要时增加mongos实例做水平扩展。
慢查询分析是性能排查的基础。使用db.currentOp()结合explain可以定位慢查询是发生在单个分片还是所有分片。对于聚合查询，可以使用allowDiskUse避免内存溢出。如果某个分片节点的CPU或IO持续偏高，需要检查该分片上的chunk数量是否过多，或者是否存在热点chunk。热点chunk可以通过迁移部分chunk到其他分片来缓解，但根本解决办法是调整分片键让写入更均匀。
# 查看mongos连接状态
mongosh --host mongos_host:27017 --eval "db.serverStatus().connections"
# 对查询进行执行计划分析
db.orders.find({createTime: {$gte: ISODate("2025-01-01")}}).explain("executionStats")
五、备份恢复与一致性检查
分片集群的备份不能只备份某个分片的数据，必须同时备份配置服务器和所有分片。如果只恢复数据分片而配置服务器元数据丢失，集群无法正确路由查询。推荐的备份方式是在低峰期停止均衡器，然后对每个组件做一致性快照。使用文件系统快照或云盘快照时，要确保所有节点在同一时间点附近完成快照，避免恢复后出现元数据与数据不一致。
恢复分片集群的顺序也很关键。先恢复配置服务器副本集，确认其能正常选举出主节点，再逐个恢复各分片副本集。恢复完成后，检查sh.status()确认chunk分布与备份时一致，使用db.printShardingStatus()查看分片详细信息。如果恢复后发现某些chunk缺失或重复，可以手动执行sh.cleanupOrphaned()清理孤儿数据，但该操作需要谨慎执行，最好在业务低峰期进行。
一致性检查还可以对比配置服务器中的chunk元数据与实际分片中的数据范围。如果发现某个分片上的数据不属于任何已知chunk，说明存在孤儿文档，需要清理。反之，如果某个chunk在配置服务器中存在但实际分片上没有数据，可能是迁移中断导致的，需要重新迁移或手动修复元数据。定期执行db.adminCommand({connPoolStats:1})查看连接池状态，也能提前发现潜在的连接泄漏问题。
// 停止均衡器后执行一致性检查
sh.setBalancerState(false)
sh.status(true)
use config
db.chunks.find({"ns" : "mydb.mycollection"}).sort({min:1})
六、一个典型的恢复场景示例
假设一个分片集群中，某一shard复制集的主节点宕机，同时配置服务器副本集也有一个节点离线，导致集群写操作失败。先不要急着重启所有服务，而是列出当前各组件的状态：登录任意mongos执行sh.status()，如果返回错误，检查mongos日志确认配置服务器连接是否正常。如果配置服务器只剩下一个节点在线，立即恢复另一个配置服务器节点，确保多数派可用。
配置服务器恢复后，再处理shard复制集。启动一个新的mongod实例，使用相同的副本集名称和--shardsvr参数加入原复制集，然后执行rs.add()将新节点添加进来。等待新节点完成初始同步后，如果原主节点无法恢复，可以强制将某个从节点提升为主节点，使用rs.stepUp()或调整优先级。主节点恢复后，写操作自动恢复，mongos会重新路由到新的主节点。
整个恢复过程中要注意保持均衡器关闭，避免在集群不稳定时触发chunk迁移导致二次故障。恢复完成后，再手动检查各分片数据是否完整，确认没有chunk卡在中间状态。最后开启均衡器，观察一段时间确保迁移正常。这类故障恢复的关键是不要跳跃操作，先恢复元数据，再恢复数据节点，最后验证一致性。
MongoDB分片集群故障处理chunk迁移修改时间：2026-09-25 14:05:40