业务事务持有了IX锁，需要在事务提交后释放该锁。日志显示，卡在写decision阶段，因为持久化这个过程是写大多数的。分析内核的metrics数据，发现这个大多数点对应时间点没有推进，从节点没有applyoplog（commit点没有推进/从上的optime一直没变）。分析从节点为何没有更新，主从同步使用getMore请求拉取oplog。
云数据库MongoDB采用副本集架构，包含Primary节点与Secondary节点。Primary节点接收并处理客户端的读写请求，且系统中仅允许一个Primary节点。Secondary节点通过周期性轮询Primary节点的oplog（操作日志）来复制数据，确保与Primary节点的数据一致性。
在复制集中，MongoDB在事务提交时记录一条oplog，包含所有操作，备节点拉取并本地重放。事务oplog示例包含操作的lsid、txnNumber和操作日志。重放过程确保事务的一致性。为了实现多文档事务的一致性，MongoDB通过WiredTiger事务来确保对数据、索引和oplog的原子性修改。
replica set恢复正常。 如果seconde出现故障，（not reachable/healthy），这时候，primary member自动降级为 seconde member，replica set中不存在primary member，无法提供写操作，数据会丢失。
MongoDB 丢数据的说法已经出现很久很久了，传言甚多。这里简单总结下场景。 在MongoDB很早的版本，0之前，没有journal，加上默认不是安全写，系统一宕机就可能出现数据丢失，因为数据没有刷盘，也没有恢复日志恢复机制。
