背景
在内部针对 MongoDB 4.4 的测试中，我们发现在带写压力的情况下对主库进行 unclean shutdown （kill -9），主库在重启之后少了很多数据，通过分析日志可以看到在加载完 stable checkpoint，进行 replication recovery，即 apply oplog 之前，有很多在 oplogTruncateAfterPoint 之后的 oplog 被 truncate 掉了，导致只有很少的 oplog 被加载。
{"t":{"$date":"2021-01-27T16:40:22.601+08:00"},"s":"I", "c":"REPL", "id":21557, "ctx":"SwitchWarmStandbyThread","msg":"Removing unapplied oplog entries after oplogTruncateAfterPoint","attr":{"oplogTruncateAfterPoint":{"":{"$timestamp":{"t":1611736805,"i":1799}}}}}
{"t":{"$date":"2021-01-27T16:40:22.651+08:00"},"s":"I", "c":"REPL", "id":21553, "ctx":"SwitchWarmStandbyThread","msg":"Truncating oplog from truncateAfterOplogEntryTimestamp (non-inclusive)","attr":{"truncateAfterOplogEntryTimestamp":{"$timestamp":{"t":1611736805,"i":1799}},"oplogTruncateAfterPoint":{"$timestamp":{"t":1611736805,"i":1799}}}}
{"t":{"$date":"2021-01-27T16:40:22.656+08:00"},"s":"I", "c":"REPL", "id":21554, "ctx":"SwitchWarmStandbyThread","msg":"Replication recovery oplog truncation finished","attr":{"durationMillis":55}}
{"t":{"$date":"2021-01-27T16:40:22.657+08:00"},"s":"I", "c":"REPL", "id":21544, "ctx":"SwitchWarmStandbyThread","msg":"Recovering from stable timestamp","attr":{"stableTimestamp":{"$timestamp":{"t":1611736795,"i":1259}},"topOfOplog":{"ts":{"$timestamp":{"t":1611736805,"i":1799}},"t":1},"appliedThrough":{"ts":{"$timestamp":{"t":0,"i":0}},"t":-1},"oplogTruncateAfterPoint":{"$timestamp":{"t":0,"i":0}}}}
...
{"t":{"$date":"2021-01-27T16:40:25.860+08:00"},"s":"I", "c":"REPL", "id":21536, "ctx":"SwitchWarmStandbyThread","msg":"Completed oplog application for recovery","attr":{"numOpsApplied":14901,"numBatches":19,"applyThroughOpTime":{"ts":{"$timestamp":{"t":1611736805,"i":1799}},"t":1}}}在 4.2 及之前的版本中，oplogTruncateAfterPoint 只用于备库，用来保证 oplog batch 应用的原子性，最终目的是确保主备数据的一致性，但是在 4.4 中主库也会维护 oplogTruncateAfterPoint ，而这个问题根本原因就是由 oplogTruncateAfterPoint 在 4.4 中的作用变化导致，下面简要分析一下。
分析
在 4.2 中 oplogTruncateAfterPoint 只有备库会维护，用来保证 oplog batch write 的原子性，主库是不需要维护的（有 replset.oplogTruncateAfterPoint集合，但是对应的 value 总是TImestamp(0,0)空值），所以主库在 replication recovery 时不会进行 oplog 的 truncate。
但是在 4.4 中，主库也会维护 oplogTruncateAfterPoint，这个做的原因是和 oplog hole 相关。
oplog hole 是因为事务在 WiredTiger 层面的提交顺序和 oplog 顺序不一致导致，复制时如果要保证主备一致性需要避开这个 hole，这个大家应该都比较熟悉了，不做展开。
但是我们考虑一个场景，op1，op2，op3 三条 oplog，对应三个事务，在 WT 层面的提交顺序为 op1，op3，op2，那么当 op2 也成功提交后，1~3 这三条 oplog 对应备库来说显然是 no hole，可以放心复制。但是即使 no hole，我们也需要需要区分是 in-memory no hole ，还是 on-disk no hole。
因为 op2 对应的 WAL 在 unclean shutdown 的情况下，因为在尾部是可能丢失的。如果备库在 in-memory no hole 的条件下就对 op 1~3 做了复制，那么在主库在重启的时候，不管是继续做主还是降级为从，都会和副本集其他成员数据不一致（缺失了 op2）。
在分析 4.2 和 4.4 是怎么避免上面这个问题之前，我们需要先了解下 in-memory no hole 是怎么维护的，这个在 4.2 和 4.4 中的方式是一样的。
在更早的版本，比如 3.2，3.4 ，是通过在 server 层自己维护一个队列来跟踪 oplog 对应的事务的提交情况来确定到哪个点是 no hole 的。由于在 4.0 之后，server 层都使用了带时间戳的事务，而这个时间戳实际上是 oplog 中的 ts 字段（ PS：这个时间戳在事务开始前就申请好了），所以可以依靠引擎层（WT）来告知我们截止到哪个时间点之前的事务都提交了，这个事情对于引擎来说很容易做到，也更应该由它们来做。这个时间点在 WT 中被称之为 all_durable，但是千万不要被这个坑爹的 “durable” 给欺骗了，它并不是真正的说事务被持久化了，见这段注释，
/**
* Manages oplog visibility.
*
* On demand, queries WiredTiger's all_durable timestamp value and updates the oplog read timestamp.
* This is done asynchronously on a thread that startVisibilityThread() will set up.
*
* The WT all_durable timestamp is the in-memory timestamp behind which there are no oplog holes
* in-memory. Note, all_durable is the timestamp that has no holes in-memory, which may NOT be
* the case on disk, despite 'durable' in the name.
*
* The oplog read timestamp is used to read from the oplog with forward cursors, in order to ensure
* readers never see 'holes' in the oplog and thereby miss data that was not yet committed when
* scanning passed. Out-of-order primary writes allow writes with later timestamps to be committed
* before writes assigned earlier timestamps, creating oplog 'holes'.
*/4.2 和 4.4 正是依靠从 WT 查询 all_durable timestamp 来获得 in-memory no hole point，并设置 oplogReadTimestamp，所有需要需要读 opog 的场景（复制，changeStream 等）都需要基于 oplogReadTimestamp 来读，oplogReadTimestamp 之后的 oplog 对读者不可见（可能有 hole(坑) :-)）。
既然从 WT 拿到的是 in-memory no hole 的时间戳，4.2 是如何避免上面那个 unclean shutdown 导致的问题的？4.2 在从 WT 获取到 all_durable ts 之后，还会等待这个 ts 之前的事务全部都持久化（WAL 刷盘）才会设置新的 oplogReadTimestamp，
// 4.2: src/mongo/db/storage/wiredtiger/wiredtiger_oplog_manager.cpp
const uint64_t newTimestamp = fetchAllDurableValue(sessionCache->conn());
// The newTimestamp may actually go backward during secondary batch application,
// where we commit data file changes separately from oplog changes, so ignore
// a non-incrementing timestamp.
if (newTimestamp <= _oplogReadTimestamp.load()) {
LOG(2) << "No new oplog entries were made visible: " << Timestamp(newTimestamp);
continue;
}
// In order to avoid oplog holes after an unclean shutdown, we must ensure this proposed
// oplog read timestamp's documents are durable before publishing that timestamp.
sessionCache->waitUntilDurable(/*forceCheckpoint=*/false, false); // 这里显式等待这个方式实际上是杜绝了备库可能复制到比主库更多数据的可能，但是这么做的缺点是会导致复制延迟的增加（毕竟需要等到事务提交并且落盘才能复制到备库），而 unclean shutdown 显然是一种很不常见的 case，不应该因为这个影响通用场景。所以在 4.4 中对这里做了优化，主库更新 oplogReadTimestamp 不再调用 waitUntilDurable 等待刷盘，而是 WAL 刷盘的过程中，异步的去更新 oplogTruncateAfterPoint，主库上的 oplogTruncateAfterPoint 表示这之前的 oplog 是 on-disk no hole 的。
// 4.4: src/mongo/db/repl/replication_coordinator_external_state_impl.cpp
JournalListener::Token ReplicationCoordinatorExternalStateImpl::getToken(OperationContext* opCtx) {
// If in state PRIMARY, the oplogTruncateAfterPoint must be used for the Durable timestamp in
// order to avoid majority confirming any writes that could later be truncated.
//
// TODO (SERVER-45847): temporary hack for the ephemeral storage engine that passes in a nullptr
// for the opCtx. The ephemeral engine does not do parallel writes to cause oplog holes,
// therefore it is safe to skip updating the oplogTruncateAfterPoint that tracks oplog holes.
if (MONGO_likely(opCtx)) {
auto truncatePoint = repl::ReplicationProcess::get(opCtx)
->getConsistencyMarkers()
->refreshOplogTruncateAfterPointIfPrimary(opCtx); // 更新主库 oplogTruncateAfterPoint
if (truncatePoint) {
return truncatePoint.get();
}
}
// All other repl states use the last applied.
return repl::ReplicationCoordinator::get(_service)->getMyLastAppliedOpTimeAndWallTime();
}在真的出现 unclean shutdown 时，主库重启时会把 oplogTruncateAfterPoint 之后的 oplog 清理掉，避免出现和副本集其他成员不一致，而自己还不感知的情况。
至此就分析清楚了，最开始问题的原因，因为测试过程中总是 kill -9 的（unclean shutdown），在带写压力的情况下切换，oplogTruncateAfterPoint 肯定是没有更新到最新的 oplog ts，导致新主库部分 oplog 没有加载。
验证：通过 kill（clean shutdown），而不是 kill -9 来触发切换，可以看到数据不会变少。
影响
初看之下，主库允许备库复制自己还没有完全持久化的 oplog，似乎副本集的持久化能力降低了，但仔细思考一下，持久化能力实际是增强了。
考虑一下上面那个 op 1-3 的例子，op2 最后提交，如果说在 op2 持久化之前，主库 crash 了，在 4.2 里面，新的主库实际上是没有 op1-3 的数据的（虽然对用户返回写成功了），但是在 4.4 里面因为不等 op2 持久化就复制，那么新主库有这个数据。在分布式环境下，复制也是持久化能力的一部分，更低的复制延迟就意味着在整个分布式系统层面更好的持久性。
