MongoDB副本集主节点宕机后端点自动切换及mongos使用咨询

• 不需要额外部署代理组件，直接用MongoDB官方驱动自带的拓扑感知能力，就能实现主节点切换时的应用侧自动路由
• 具体配置方式非常简单：在应用的数据库连接串里，把副本集3个节点的所有endpoint全部填进去，同时指定当前副本集的名称参数。参考格式：
  mongodb://node1-endpoint:27017,node2-endpoint:27017,node3-endpoint:27017/?replicaSet=你的副本集名称&readPreference=primary
• 运行逻辑：驱动启动后会自动探测整个副本集的节点角色，实时同步哪个节点是可写入的PRIMARY；当旧主宕机、新主完成选举后，驱动会在数秒内感知到拓扑变化，自动把所有写请求转发到新的主节点上，全程不需要应用手动改配置或者重启。
• 适配提醒：因为你的应用仅支持向主节点发起写入，一定要把读偏好固定配置为primary，避免驱动错把写请求发到从节点上触发报错；另外要使用2.0以上版本的各语言官方驱动，老旧驱动的拓扑感知能力不完善，可能出现切主延迟高、断连不恢复的问题。

针对你提到的两个相关疑问，直接给出明确结论：

1. 你当前这套单副本集的架构，完全不需要部署mongos
2. 你印象中“mongos必须配合分片集群才能使用”的认知，是生产环境的常规落地经验，但不是技术上的强制规则：
   • mongos本质是无状态的路由进程，最初设计出来是给分片集群做请求拆分、分片路由的，但它本身也支持连接单个非分片的副本集，自动感知副本集拓扑、把请求转发到当前的主节点上。
   • 这种单副本集+mongos的用法在生产环境几乎没人用，原因很实在：相比直接用驱动原生的拓扑感知能力，引入mongos会多一层网络跳转，还得单独维护一组mongos高可用进程，平白增加故障点和运维成本，没有任何收益。
   • 只有当你的应用用了完全不支持副本集拓扑感知的超老旧驱动、而且没法升级驱动版本的时候，才会考虑临时架mongos当兼容层，给应用提供一个固定的访问地址，由mongos去做主节点切换的感知逻辑。
3. 额外避坑提醒：别用普通四层负载均衡（比如LVS、基础Nginx反向代理）给副本集做统一访问入口，这类组件识别不了节点的主从角色状态，会随机把写请求分发到从节点，导致应用频繁报not primary的写入错误。

内容的提问来源于stack exchange，提问作者ananta