mongodb 5.0分片集群中可重试写入默认启用但需同时满足：驱动版本兼容（如node.js v3.6+）、连接字符串显式指定retrywrites=true、所有mongod节点（含csrs和分片）及mongos均为4.4+；不满足任一条件则静默降级为不可重试。
MongoDB 5.0 分片集群中，可重试写入默认已启用，但必须满足三个硬性前提：驱动版本兼容、连接字符串显式开启、且所有 mongod 节点运行在 4.4+（推荐 5.0+）。 不满足任一条件，retryWrites=true 会被静默忽略，写操作失败后不会自动重试。
确认驱动支持并启用 retryWrites 参数
可重试写入是客户端驱动行为，不是服务端开关。MongoDB 5.0 服务端仅提供协议支持，实际重试逻辑由驱动完成。
- Node.js 驱动 v3.6+、Python PyMongo v3.12+、Java Driver v4.3+ 才完整支持分片集群下的可重试写入；旧版本即使加了参数也无效
- 连接字符串中必须显式包含
retryWrites=true，例如：mongodb://mongos1:27017,mongos2:27017/?replicaSet=rs0&retryWrites=true - 不能只依赖默认值——即使文档说“默认 true”，在分片集群中，若未在连接字符串或客户端选项里明确声明，驱动会退回到不可重试模式
- 使用
mongosh连接时，该参数不生效；mongosh是管理 shell，不实现可重试写入逻辑
确保所有 mongod 节点支持可重试写协议
分片集群包含三类 mongod：配置服务器（CSRS）、分片副本集成员、以及 mongos（虽非 mongod，但需转发协议）。其中任意一个组件版本过低，都会中断重试链路。
- 所有
mongod实例（包括 CSRS 和分片）必须为 MongoDB 4.4 或更高版本；4.2 及更早版本不识别retryWrites协议位，会直接拒绝带该标志的请求 - mongos 进程版本必须 ≥ 所有后端 mongod 的最低版本；例如，若分片用 5.0，mongos 不能是 4.4 —— 否则它无法正确解析和转发重试上下文
- 检查方式：连接任意 mongos 后执行
db.runCommand({getCmdLineOpts: 1})，确认parsed.sharding.clusterRole和parsed.replication.replSetName存在且合法，再查db.version()输出
避免常见失效场景
即便参数写了、版本对了，以下情况仍会导致可重试写入静默降级：
- 对未分片集合执行写入：可重试写入只在分片集群中对 分片集合 生效；对数据库内普通集合（即未执行
sh.enableSharding()和sh.shardCollection()的集合），驱动不会触发重试 - 使用了不支持的写命令：如
findAndModify（已弃用）、group、或带let+ 聚合管道的更新，这些操作不纳入可重试范围 - 事务内写入：可重试写入与多文档事务互斥；一旦进入
session.startTransaction()，所有写操作走事务协议，不再受retryWrites控制 - 网络层干扰：某些代理、负载均衡器或 TLS 中间件会剥离或篡改 OP_MSG 头部中的重试标志位，导致服务端收不到该语义
真正容易被忽略的是 mongos 和分片 mongod 的版本对齐问题——很多人只升级了分片，忘了更新 mongos 二进制，结果整个集群的可重试能力形同虚设。验证时别只看一个节点，得逐个 mongos 和每个分片副本集主节点都跑一遍 db.version()。
