MongoDB不支持LDAP多地址自动故障转移，仅接受单个ldap://URI，连接失败即报AuthenticationFailed错误；替代方案需依赖HAProxy等外部代理或应用层手动轮询，且LDAP功能已在8.0版本弃用。
MongoDB 不支持多个 LDAP 服务器自动故障转移。官方驱动和 mongod/mongos 进程本身没有内置机制去轮询、探测或切换多个 LDAP 地址——连接失败即报错，不会 fallback 到备用地址。
LDAP 配置只接受单个 URI，且不解析逗号分隔列表
你不能像写 mongodb://mongos1:27017,mongos2:27017/ 那样写多个 LDAP 地址。MongoDB 的 LDAP 支持（通过 ldap.uri 或 --ldap-uri）只接受一个标准 LDAP URI，例如：
ldap://ldap1.example.com:389
若该地址不可达，认证直接失败，AuthenticationFailed 错误抛出，无重试逻辑。即使你在 DNS 层做了多记录（如多个 A 记录），glibc 或系统 resolver 行为不可控，MongoDB 不做 SRV 解析或健康探测。
替代方案：用前置代理或负载均衡器兜底
真正可行的“故障转移”必须由外部组件承担，MongoDB 仅作为客户端消费统一入口：
- 部署 HAProxy 或 nginx 作为 LDAP 代理，后端挂多个 LDAP 服务器，配置健康检查 + failover 策略
- 使用 DNS 轮询（如
ldap-lb.example.com解析到多个 IP），但需确保客户端库启用reconnect且超时足够短（否则会卡在已宕机节点上） - 在应用层封装 LDAP 认证逻辑，自行实现多地址顺序尝试（比如用 Python 的
ldap3库手动遍历列表）
注意：mongod --ldap-uri 不支持 ldaps:// 与 ldap:// 混用；TLS 配置（如 ldap.tlsCAFile）也只作用于单一 URI。
LDAP 已在 MongoDB 8.0 中被标记为弃用
从 mongod 8.0 开始，ldap 相关参数（如 ldap.uri、ldap.bindQueryUser）仍可用，但官方明确声明：将在下一个主版本中移除。当前所有新项目应优先评估 SCRAM-SHA-256 + 外部身份代理（如 Dex、Keycloak）或 Atlas IAM 集成路径。硬依赖 LDAP 多活，等于锁定旧架构并承担未来升级风险。
最常被忽略的一点是：即使你用代理实现了 LDAP 故障转移，MongoDB 自身的用户元数据（system.users）仍只存一份，不复制、不同步。如果代理把请求打到了不同 LDAP 服务器，而它们的用户命名空间或组映射规则不一致，权限行为就会不可预期。
