MongoDB事务中为何不能修改Read Preference？解析主节点写入与事务会话限制
事务中设置 readPreference 会直接报错
想在MongoDB事务里换个节点读数据？这事儿行不通。一旦在开启了事务的会话中——无论是通过session.withTransaction()还是手动session.startTransaction()——尝试执行类似collection.find().readPreference('secondary')的操作，驱动会立刻给你一个明确的拒绝：Read preference in a transaction must be primary。
这可不是驱动在“多管闲事”，而是MongoDB Server（4.0版本及以上）的硬性规定。在事务的上下文中，服务器会直接拒绝任何readPreference不是primary的请求。道理很简单：即便是单纯的读操作，也必须和事务内的写操作共享同一份数据视图（即主节点上最新的oplog位置）。否则，事务最核心的原子性和一致性保障就可能被破坏。
- 所以，只要在事务会话内，哪怕你只读不写，
readPreference也绝不能设为'secondary'或'nearest'这类选项。 - 显式传入
{ readPreference: 'primary' }是合法但多余的；不传的话，会话会自动采用primary作为默认值。 - 这里有个细节需要注意：在Node.js驱动中，通过
session.getDatabase().collection('x')获取的集合实例，其读偏好继承自会话级别，而不是客户端或连接池的全局设置。
为什么主节点是唯一安全选项
那么，为什么事务必须“绑定”在主节点上呢？核心在于“因果一致性”这个要求。事务要求所有读写操作都基于同一个复制集成员的最新状态，而这个成员必须有能力接受写入——那自然就是主节点了。从节点（Secondary）存在固有的复制延迟，它的数据快照很可能落后于主节点。想象一下，如果事务已经修改了某些数据（但尚未提交），却允许从另一个延迟的节点去读，那读到过期值或者出现“不可重复读”这类隔离性问题，几乎是必然的。
更深层的原因在于事务的协调机制。MongoDB事务依赖两阶段提交（2PC）协议，而这个协议是由主节点来协调的。所有参与者（包括主节点自身）的状态同步都通过这个节点进行。如果允许从其他节点读取，就等于绕开了这个唯一的协调者所持有的数据视图，事务引擎根本无法保证你的读操作能看到一个“在事务内保持一致性的快照”。
- 实际上，事务内的
find()操作走的是主节点上的“快照读”，而非普通查询路径。这个快照由事务开始时的会话ID（lsid）和事务号（txnNumber）共同锁定。 - 试图在事务中切换
readPreference，本质上等同于让一个事务跨越多个数据版本，服务器层会在查询执行前就直接拦截。 - 因此，无论你在副本集配置里设置了
sla veOk: true，还是在连接字符串中写了readPreference=secondary，这些设置在事务会话里统统无效。
常见误用场景与替代方案
开发者们常出于性能优化或分散负载的好意，在事务里尝试降低读请求的级别，结果却触发了报错或隐性的失败。典型的误用场景包括：在事务回调函数里调用设置了readPreference的聚合操作、使用collection.aggregate().readPreference('secondary')进行中间计算，或者复用了之前配置了非主节点读偏好的集合实例。
- 记住，不要在事务的回调函数内部新建一个带有非
primary读偏好配置的集合对象。驱动不会自动覆盖这个配置，它会沿用你创建时的设置，然后导致报错。 - 如果事务逻辑中包含大量只读操作，一个可行的替代方案是将其拆分为“事务外预读 + 事务内确定性操作”。例如，先在事务外查询出需要的ID列表，再在事务内根据这些ID进行批量更新。
- 对于那些对延迟不敏感的报表类读取，应该彻底移出事务范围。记住一个原则：事务应该尽可能短小，长时间的事务会阻塞主节点的写入。
- 使用
session.withTransaction()时，其回调函数内部的所有数据库操作自动共享同一个会话，你既不需要也不应该手动去设置readPreference。
驱动版本与兼容性注意点
不同版本的驱动在处理这个问题时行为可能不同。较早的Node.js驱动（比如3.x系列）可能在事务中会忽略readPreference设置，但行为并不一致。而从4.0版本开始的驱动，则严格遵循服务器规则，遇到非法偏好设置会立即抛出错误。这个限制同样适用于Python的PyMongo和Ja va驱动等。
- 在Driver 4.13+版本中，虽然构造
ClientSession时支持传入defaultTransactionOptions，但这个选项对象里并不包含readPreference字段——因为它被硬编码为primary了。 - 连接字符串中指定的
readPreference=primaryPreferred不会影响事务内部，事务内依然强制使用primary。不过，这个设置对连接上的非事务操作是有效的。 - 使用
mongosh进行测试时，像session.startTransaction({ readConcern: { level: 'snapshot' } })这样的写法是合法的，但如果你试图加入readPreference字段，则会直接引发语法错误。
说到底，事务并非万能的读写封装工具，它带来的强一致性约束和节点绑定是有代价的。在决定把一个读操作塞进事务之前，最好先问自己一句：它真的需要和写操作共享同一份数据快照吗？大多数情况下，答案可能是否定的。
