MongoDB副本集主节点选举期间写入被拒，如何避免业务500错误？

这是MongoDB副本集的已知固有特性：副本集必须保证同一时间只有一个主节点接收写入请求，选举过程中不存在合法的可写入主节点，因此写入会被拒绝，无法完全消除选举期间的写入不可用窗口，只能通过以下方案尽可能缩短不可用时长、或对业务侧屏蔽不可用影响：

客户端侧优化 #

• 你已配置的retryWrites=true参数已经覆盖了大部分自动重试场景：@nestjs/mongoose v6.4依赖的node-mongodb-native 3.x及以上驱动，会自动对幂等写入操作（单文档插入、更新、删除）在主节点恢复后自动重试，无需额外修改业务代码。非幂等写入操作建议添加唯一幂等键后，手动配置重试逻辑避免重复写入。
• 业务层增加统一的退避重试机制：在全局异常拦截层捕获NotWritablePrimary（错误码10107）、not master类错误，采用指数退避策略重试，最大重试时长设置为5秒即可覆盖绝大多数选举场景的不可用窗口，避免直接返回500错误给前端。
• 非核心可延迟写入的业务可以引入本地消息队列兜底：写入请求先入队列立即返回用户成功，后台异步消费写入MongoDB，选举结束后自动追平写入数据。

集群配置侧优化 #

• 调整副本集选举相关参数：MongoDB Atlas默认已对选举流程做了优化，你可以在Atlas控制台调整副本集心跳检测间隔、选举超时阈值，将选举窗口尽可能压缩到2秒以内。
• 开启滚动扩缩容模式：联系Atlas技术支持开启自动扩缩容的滚动升级策略，扩容时先升级两台从节点规格，再触发主节点切换，大幅降低主节点不可用的时长。
• 核心零中断写入场景可迁移至分片集群架构：分片集群每个分片为独立副本集，单个分片的主节点选举只会影响该分片对应数据的写入，不会导致全量写入业务不可用。

业务层降级适配 #

• 对一致性要求不高的写入操作做同步降级：用户提交请求后先返回操作成功，后台异步保证写入最终完成，无需同步等待MongoDB响应。
• 对强一致要求的核心写入操作，可以在选举期间给用户返回「系统繁忙，请稍后重试」的友好提示，代替无意义的500错误。

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