能，mongos宕机后已有连接且路由缓存未过期时，普通查询和写入仍可正常转发；但新连接无法建立，getMore、事务及所有分片管理操作立即失效，缓存过期后路由失败。
不影响业务读写，但会中断所有分片管理操作和客户端连接路由能力。
mongos宕机后普通查询和写入还能用吗
能，前提是客户端已建立连接且路由缓存未过期。mongos本身不持久化数据，只做请求转发；它从config server拉取的路由表（shard分布、chunk范围）默认缓存30秒。只要缓存有效，已有连接仍可正常转发请求到对应shard，find、insert、update等操作不受影响。
- 新连接无法建立：客户端尝试新建连接时，若目标mongos进程已退出，会直接报
connection refused或No route to host - 缓存过期后无法刷新：30秒后若mongos仍未恢复，后续请求会因找不到路由而失败，错误类似
failed to refresh metadata: config server is unreachable（注意：这不是config server挂了，而是mongos自己挂了导致无法主动刷新） - getMore和事务必然失败：因为
cursorID和logicalSessionId只存在于当前mongos内存中，换节点就查不到上下文
哪些分片管理命令会立即失效
所有依赖mongos协调元数据变更的操作都会被拦截，不是排队等待，而是直接拒绝。
-
sh.moveChunk、sh.splitAt、sh.migrateChunk：报错cannot acquire global lock for metadata write -
sh.enableSharding、sh.addShard、sh.removeShard：返回config server is not available（实际是mongos不可用，但错误信息误导性很强） -
sh.status()仍可执行：返回的是最后一次成功加载的缓存快照，不是实时状态
为什么不能靠“多启几个mongos”就高枕无忧
mongos节点之间不共享状态，每个都是独立路由实例。问题不在数量，而在客户端如何抵达它们。
- 负载均衡策略必须保证
getMore和事务请求落到同一mongos：源IP Hash只是基础，若客户端重连或LB故障切换，就会断cursor - systemd或容器编排中误用通用
mongod服务单元：重启时可能把config server或shard当mongos启，导致--configdb参数缺失，mongos启动成功但sh.status()显示config server status: Unknown - 没配健康检查：LB层若只探活端口，不验证
db.runCommand({ping: 1})，会把假死的mongos继续导流
真正容易被忽略的是：mongos宕机本身不丢数据，但会让整个集群失去“动态调节能力”。比如某个shard因热点变慢，均衡器本该触发chunk迁移，结果卡在isBalancerRunning返回false——你得先恢复mongos，再手动sh.startBalancer()，中间这段时间负载不均可能已经拖垮下游应用。
