dev/MultiforaDB
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

db/commands: acknowledged writes reach the disk again

Browse Source 
Three defects, each of which made the database lose data that had already
been acknowledged, or answer a client with a malformed reply.

- Engine.commit decided a writer was "already covered" by comparing
  log.end_pos with the position of the last completed commit. Under block
  framing an append leaves its bytes in the log's open in-memory block and
  does not move end_pos -- only sealing does. So once the first commit had
  set committed_end = end_pos, every later write command found itself
  covered and returned without sealing or syncing anything. A no-op
  deleteMany followed by insertMany(50) was acknowledged with the file
  still 16 bytes (its header) and lost all 50 documents on kill -9, which
  is precisely what e2e2's crash pair does. Coverage is now decided by
  sequence number, which counts records rather than bytes on disk.

- Compaction read the new log's end position before syncing it, but the
  sync is what seals the open block, and the seal is what moves end_pos
  past it. Appends after a compaction therefore started inside the
  compacted file's last block and overwrote it, so those documents were
  gone at the next replay: e2e6's phase 2 ended with 1000 documents in
  memory and 996 after a graceful restart.

- cmd_find returned early on a missing namespace without putting anything
  in the reply, so a find on an unknown collection arrived at the driver as
  a response with no `ok` field ("MongoServerError: n/a") instead of an
  empty cursor. The other commands' missing-namespace paths were fine.

Verified with the unit suite in ReleaseFast/ReleaseSafe/Debug, the split
fuzzer, all six e2e suites (e2e6 back to 72/72) and the kill -9 crash pair
-- none of which passed beforehand -- plus 13 kill -9 runs over 1/2/8
connections with 1200 acknowledged inserts each and nothing lost.

tests/e2e/results/phase7.txt records the benchmark with the fixes in place:
no regression against phase6 (bulk 739 -> 753 MB/s, updateMany 1.9 -> 2.0
ms, RSS 547 -> 546 MB), and concurrent durable writes now measurable at
7.1k/15.0k/21.8k docs/s over 1/8/32 connections.
This commit is contained in:
Alexey Shakhmatov
2026-08-03 00:09:11 +03:00
parent ecd28d9b26
commit c8d547fef5
3 changed files with 89 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
tests/e2e/results/phase7.txt Normal file
View File

@@ -0,0 +1,58 @@
# Phase 7 gate — mongo-lite vs MongoDB 8.3.7, 1g dataset / ~16k docs
# Ratio < 1.0 = mongo-lite faster. Reproduce: bash tests/e2e/compare-run.sh 1g 16k
# All five roadmap items plus the three durability/correctness fixes below.
# Compare: tests/e2e/results/phase6.txt (same code, broken commit path) and
# tests/e2e/results/phase1.txt (pre-tree baseline).
benchmark mongo-lite mongodb ratio
insertOne (sequential) ×200 0.19 ms 4.9 ms 0.0x
bulk insert throughput 753.5 MB/s 704.6 MB/s 1.1x
docs loaded 65,536 65,536 1.0x
createIndex({k: 1}) 75.7 ms 75.5 ms 1.0x
countDocuments({}) 3.4 ms 11.2 ms 0.3x
findOne({_id: <ObjectId>}) 0.61 ms 0.63 ms 1.0x
findOne({k: 500}) (indexed) 0.57 ms 2.3 ms 0.2x
find({p: {$gte,$lt}}).count() (scan) 13.5 ms 14.6 ms 0.9x
find({}).sort({_id:-1}).limit(20) 2.3 ms 2.5 ms 0.9x
find({}, {proj}).limit(1000) 3.7 ms 4.4 ms 0.8x
aggregate $group by k 8.3 ms 15.1 ms 0.5x
updateOne({_id}) ×50 0.16 ms 0.20 ms 0.8x
updateMany({k: 7}, {$inc}) 2.0 ms 5.3 ms 0.4x
deleteOne({_id}) + insertOne 0.58 ms 5.0 ms 0.1x
node client RSS 153 MB 154 MB 1.0x
server RSS 546 MB 1424 MB
kill -9 reopen 0.8s 1.3s
db on disk 97MB 95MB
# No regression from the fixes. Against phase6 (which measured a commit path
# that mostly skipped its fsync): bulk 739 -> 753.5 MB/s, insertOne 0.20 ->
# 0.19 ms, updateMany 1.9 -> 2.0 ms, RSS 547 -> 546 MB, disk and reopen
# unchanged — all within run noise. The real fsync per commit does not show
# here because this benchmark is single-connection and writes through large
# insertMany batches, so one commit is amortized over the whole batch.
#
# What phase6 could not have measured, because the crash pair did not pass:
# - kill -9 durability: 13 runs over 1/2/8 connections, 1200 acknowledged
# inserts each, zero lost.
# - concurrent durable writes (sequential insertOne per client):
# 1 client 7.1k docs/s | 8 clients 15.0k | 32 clients 21.8k.
#
# Fixes in this commit (each reproduced before it was fixed):
# 1. Engine.commit compared log.end_pos with the last committed position to
# decide a writer was already covered. Under block framing an append
# leaves its bytes in the log's open block without moving end_pos, so
# after the first commit every later write command returned without
# sealing or syncing. A no-op deleteMany followed by insertMany(50) was
# acknowledged with the file still 16 bytes (header only) and lost
# everything on kill -9. Coverage is now by sequence number.
# 2. Compaction read new_end_pos before new_log.sync(), but the sync is
# what seals the open block and moves end_pos past it, so later appends
# overwrote the compacted file's last block. e2e6's phase 2 ended with
# 1000 documents in memory and 996 after a graceful restart.
# 3. cmd_find returned without a reply on a missing namespace, so find on
# an unknown collection reached the driver as a malformed response
# ("MongoServerError: n/a") instead of an empty cursor.
#
# Verification: unit suite in ReleaseFast/ReleaseSafe/Debug, the split fuzzer
# (src/fuzz_split.zig), all six e2e suites (e2e6 72/72), and the kill -9
# crash pair — none of which passed before these fixes.