MongoDB事务时间戳获取及只读事务相关技术问题咨询

1. start-timestamp的正确性与atClusterTime的含义 #

• 你通过日志获取的readTimestamp就是事务的start-timestamp，完全符合SI协议中事务快照起始时间的定义，这个获取方式是正确的。
• atClusterTime是客户端操作对应的集群全局逻辑时间：
  • 对于用with_transaction API执行的多文档事务，atClusterTime会和readTimestamp始终保持一致——因为事务启动时会绑定一个固定的集群快照，这个快照时间同时作为readTimestamp和事务的atClusterTime；
  • 只有非事务的单文档操作，atClusterTime才会对应操作执行时的集群时间，和readTimestamp（如果有）无关。

2. commit-timestamp的正确性验证 #

• 从oplog.rs集合的ts字段获取commit-timestamp是正确的。MongoDB多文档事务提交时，会在oplog中生成一条applyOps类型的记录，这条记录的ts字段就是事务的全局commit-timestamp，对应SI协议中事务提交的时间点。
• 分片集群场景下，每个分片的oplog会有对应事务的分片级提交记录，但全局事务的commit-timestamp以协调器节点生成的applyOps记录的ts为准，你可以通过事务的事务ID（txnNumber）关联各分片的oplog记录。

3. 只读事务的commit-timestamp获取 #

• MongoDB 7.0.2的只读事务存在commit-timestamp，但因为只读事务没有修改数据，不会写入oplog，所以无法从oplog.rs获取。
• 可行的获取方式：
  • 调整MongoDB日志级别为debug，事务提交时的日志中会输出commitTimestamp字段，直接提取即可；
  • 利用Python驱动v4.1.1的会话元数据：在with_transaction执行完成后，通过会话对象的transaction_context属性（或调用get_transaction_context()方法）可以获取包含commit-timestamp的事务元数据；
  • 替代方案：在只读事务的最后执行db.runCommand({ping: 1})，返回结果中的operationTime就是事务提交时的集群逻辑时间，可作为commit-timestamp的近似值，但精度略低于前两种方式。

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