maxConns 参数在 MongoDB 副本集中基本不生效；自 3.4 版本起已被弃用，实际连接数受操作系统文件描述符限制、驱动连接池配置及网络中间件超时策略控制。
maxConns 参数在 MongoDB 副本集中是否生效？
maxConns 是 MongoDB 早期版本（3.2 及之前）中用于限制单个 mongod 实例最大并发连接数的配置项，但它在现代副本集部署中基本不生效——从 3.4 开始，MongoDB 默认忽略 maxConns，且官方文档明确标注为“deprecated”。即使你在 mongod.conf 中写入 maxConns: 500，启动时会静默忽略，db.serverStatus().connections 显示的当前连接数仍可能远超该值。
真正起作用的是操作系统级连接限制和 ulimit
MongoDB 实际能接受的连接数，主要受制于宿主机的文件描述符（file descriptor）上限。每个 TCP 连接占用一个 fd，而 mongod 启动时会继承 shell 的 ulimit -n 值。常见现象是：副本集节点突然拒绝新连接，日志里没有 maxConns 相关提示，但 cat /proc/$(pidof mongod)/limits | grep "Max open files" 显示软限只有 1024。
- 修改前先确认当前限制：
ulimit -n - 临时提高（仅当前 session）：
ulimit -n 65536 - 永久生效需编辑
/etc/security/limits.conf，添加两行：mongod soft nofile 65536mongod hard nofile 65536 - 若使用 systemd（绝大多数现代 Linux 发行版），还需在
/etc/systemd/system/mongod.service.d/override.conf中显式设置：[Service]<br>LimitNOFILE=65536
副本集场景下更关键的连接控制点
副本集本身不提供统一的连接数调度或限流能力，各节点独立管理连接。实际运维中，真正需要干预的通常是客户端行为和网络层：
- 驱动连接池配置比服务端
maxConns更有效：例如 Node.js 的mongodb驱动用maxPoolSize: 100控制每个实例的连接数 - 避免直连 secondary 节点做读操作却不设
readPreference=secondary，否则可能因负载不均导致某节点连接堆积 - 防火墙或负载均衡器（如 HAProxy）的 idle timeout 若短于 MongoDB 的
net.maxIncomingConnections（该参数也已废弃），反而会引发大量 TIME_WAIT 和重连风暴 - 监控应聚焦
db.serverStatus().connections.current+os.network.numRequests组合，而非依赖一个失效的maxConns
如果你必须兼容旧版本（≤3.2）或 fork 分支
极少数定制环境仍在用 3.0 或 Percona Server for MongoDB 等分支，它们可能保留 maxConns 行为。此时需注意：
- 必须在
mongod.conf的net段下设置：net:<br> maxConns: 2000
- 该值对所有副本集成员（包括 arbiter）都生效，但不会跨节点同步或协调
- 重启 mongod 后，用
db.adminCommand({getCmdLineOpts: 1})查看输出中parsed.net.maxConns是否存在且数值匹配 - 如果使用 keyfile 认证，修改配置后务必确认
security.keyFile权限仍是600，否则 mongod 拒绝启动，容易误判为maxConns导致失败
别在 maxConns 上浪费调试时间——它早已不是连接控制的实际开关。真正要盯住的是 ulimit、驱动池大小、以及网络中间件的超时策略。
