LevelDB 写入日志（WAL）深度解析：LogWriter 与 LogReader 的实现原理与崩溃恢复机制

LevelDB 写入日志WAL深度解析LogWriter 与 LogReader 的实现原理与崩溃恢复机制【免费下载链接】Tutorial-Codebase-KnowledgePocket Flow: Codebase to Tutorial项目地址: https://gitcode.com/gh_mirrors/tu/Tutorial-Codebase-Knowledge导读本文深入剖析 LevelDB 的 Write-Ahead LogWAL预写日志机制——这是保证数据库写操作一旦返回成功、数据就绝不会因断电或崩溃而丢失的核心组件。文章基于本仓库 LevelDB 系列教程的 第三章WAL 与 LogWriter/LogReader完整讲解 WAL 的写入链路先落盘、后改内存、日志文件的物理分块与分片格式以及崩溃恢复时的日志重放流程。读完本文你将掌握log::Writer与log::Reader的底层实现细节、物理记录Physical Record的五种类型kFullType / kFirstType / kMiddleType / kLastType / kBadRecord的语义并理解 WAL 与 MemTable、WriteBatch、DBImpl 之间的协作关系。背景问题崩溃时为什么会丢数据在 第二章MemTable 中我们了解到LevelDB 用内存中的MemTable类似一张快速的便签纸来快速承接新的Put与Delete写入之后再在后台将数据刷写flush成磁盘上的 SSTable 文件。这种设计极大地提升了写入速度但引入了一个致命隐患RAM 是易失性存储。如果数据已经写入MemTable、但尚未被刷写到 SSTable 时电源被拔掉或服务器崩溃那么MemTable中所有尚未落盘的数据将永久丢失。对于数据库而言这是不可接受的可靠性问题。于是核心矛盾浮出水面如何保证写操作返回成功后数据就是安全的即使系统在下一秒立刻崩溃仅依赖MemTable远远不够——它活在易失的 RAM 里。我们需要一种机制让写入在更早的时间点就获得持久性Durability。WAL数据库的航海日志LevelDB 的解决方案就是Write-Ahead LogWAL通常简称为log日志。可以把它想象成船长的航海日志或法庭书记员的速记稿先写日志再动内存Write First船长在采取任何重大行动比如改变航向之前会先把行动写进航海日志。同理LevelDB 在修改MemTable位于 RAM之前先把这次变更的描述例如Put key user1 value dataA追加写入磁盘上的一个特殊文件——WAL 文件。只追加Append-Only像日志本一样记录只是顺序追加到文件末尾。LevelDB 不会回头修改当前 WAL 文件里的旧记录。这让写入非常快——本质就是向文件末尾追加。真正落盘On Disk关键在于WAL 文件位于持久化磁盘HDD/SSD上而非仅仅存在于易失性 RAM 中。持久性Durability在向用户确认写入成功之前先把记录写入 WAL即使服务器立刻崩溃操作记录也已安全保存在磁盘日志中。因此完整的写入流程如下应用-Put(user123, data)-1. 追加到 WAL 文件磁盘-2. 写入 MemTableRAM-返回成功这个先写日志write-ahead的步骤就是持久性的保障。为什么把整个 WriteBatch 写成一条记录值得注意的是WAL 中记录的并非单条Put操作而是整个序列化后的 WriteBatch。如 第五章WriteBatch 所述DBImpl::Write会把一个WriteBatch可能包含多个 Put/Delete的完整序列化内容作为一条记录写入 WAL。这样既保证了原子性整批要么全部生效、要么全部不生效也显著减少了磁盘 I/O——将 N 次小写入合并为 1 次日志追加。崩溃恢复重放航海日志现在假设服务器崩溃后重启LevelDB 需要恢复状态。WAL 是如何发挥作用的检查日志文件LevelDB 启动时会查找是否存在 WAL 文件。读取日志如果存在 WAL 文件说明数据库可能没有干净地关闭最后一次MemTable的内容仅存在于 RAM已经丢失。LevelDB 创建一个LogReader从头到尾读取 WAL 文件。重建 MemTable对于 WAL 中找到的每条操作记录如Put key user1 value dataA、Delete key user2LevelDB 在一个新的空MemTable中重新执行re-apply该操作。就像重读航海日志还原事故发生前的现场。恢复完成整个 WAL 重放完毕后MemTable恢复到崩溃前的状态。LevelDB 可以继续正常运行接受新的读写。WAL 中的数据现在安全地存在于新的MemTable中等待之后被刷写为 SSTable。WAL 文件本质上是MemTable的临时备份直到MemTable的内容被永久存储到 SSTable 中。一旦MemTable成功刷写为 SSTable对应的 WAL 文件就不再需要可以被删除。WAL、MemTable、SSTable 三者协同WAL 为最新写入提供快速持久性MemTable 在内存中提供对这些最新写入的快速访问SSTable 为绝大部分数据提供持久化的有序存储。LogWriter日志的写入端负责把记录写入 WAL 文件的组件是log::Writer。可以把它想象成专职在航海日志上写字的书记员。当 LevelDB 处理一次写操作通常来自一个 WriteBatch时它会把这批变更序列化成一整块数据一个Slice然后交给log::Writer追加到当前日志文件中。下面是教程文档中给出的、简化自 LevelDBdb/db_impl.cc的关键调用链DBImpl::Write(...)中准备好 batch 之后// --- Simplified from db/db_impl.cc --- // Inside DBImpl::Write(...) after preparing the batch: Status status log_-AddRecord(WriteBatchInternal::Contents(write_batch)); // ... check status ... if (status.ok() options.sync) { // Optionally ensure the data hits the physical disk status logfile_-Sync(); } if (status.ok()) { // Only if WAL write succeeded, apply to MemTable status WriteBatchInternal::InsertInto(write_batch, mem_); } // ... handle status ...逐步解释WriteBatchInternal::Contents(write_batch)取出写操作的序列化表示一个或多个 Put/Delete 的打包数据。log_-AddRecord(...)调用log::Writer实例log_把这份序列化数据作为一条记录追加到当前 WAL 文件logfile_。logfile_-Sync()当options.sync为 true 时此调用通知操作系统确保日志文件数据真正抵达物理磁盘盘片/闪存而不是停留在某个 OS 缓冲区中。这对于挺过断电至关重要。WriteBatchInternal::InsertInto(write_batch, mem_)只有当日志写入被确认并且按需完成 Sync之后LevelDB 才会把变更应用到内存MemTable。物理记录格式固定块 分片log::Writer自身负责处理记录在日志文件中的具体格式化细节。日志文件由固定大小的块block组成如 32KB。AddRecord收到的一条记录可能很小、能完整塞进当前块剩余空间也可能很大需要跨块边界被拆分成多条物理记录分片fragment。// --- Simplified from db/log_writer.cc --- Status Writer::AddRecord(const Slice slice) { const char* ptr slice.data(); size_t left slice.size(); // How much data is left to write? Status s; bool begin true; // Is this the first fragment of this record? do { const int leftover kBlockSize - block_offset_; // Space left in current block // ... if leftover kHeaderSize, fill trailer and start new block ... // Calculate how much of the data can fit in this block const size_t avail kBlockSize - block_offset_ - kHeaderSize; const size_t fragment_length (left avail) ? left : avail; // Determine the type of this physical record (fragment) RecordType type; const bool end (left fragment_length); // Is this the last fragment? if (begin end) { type kFullType; // Fits entirely in one piece } else if (begin) { type kFirstType; // First piece of a multi-piece record } else if (end) { type kLastType; // Last piece of a multi-piece record } else { type kMiddleType; // Middle piece of a multi-piece record } // Write this physical record (header data fragment) to the file s EmitPhysicalRecord(type, ptr, fragment_length); // Advance pointers and update remaining size ptr fragment_length; left - fragment_length; begin false; // Subsequent fragments are not the begin fragment } while (s.ok() left 0); // Loop until all data is written or error return s; } // Simplified - Writes header (checksum, length, type) and payload Status Writer::EmitPhysicalRecord(RecordType t, const char* ptr, size_t length) { // ... format header (buf) with checksum, length, type ... // ... compute checksum ... // ... Encode checksum into header ... // Write header and payload fragment Status s dest_-Append(Slice(buf, kHeaderSize)); if (s.ok()) { s dest_-Append(Slice(ptr, length)); // LevelDB might Flush() here or let the caller Sync() later } block_offset_ kHeaderSize length; // Update position in current block return s; }要点拆解AddRecord接收用户数据slice按avail当前块剩余可用空间 kBlockSize - block_offset_ - kHeaderSize将其切分成更小的fragment_length数据块。每个数据块通过EmitPhysicalRecord写成一条物理记录。EmitPhysicalRecord会在每条物理记录前附加一个7 字节的头kHeaderSize包含校验和checksum用于检测日志损坏corruption本分片长度length记录类型RecordTypekFullType、kFirstType、kMiddleType或kLastType。一个重要的边界处理当leftover当前块剩余空间小于kHeaderSize时说明剩余空间连一个头都放不下此时会先填充一个 trailer 并开启新的块代码中以注释省略。RecordType的作用是告诉LogReader之后如何把这些分片重新拼接回完整的原始记录。LogReader恢复时的读取端与LogWriter相对的组件是log::Reader。它用于数据库启动恢复阶段从 WAL 文件中把记录读回来。可以把它想象成事故后仔细研读航海日志的人。log::Reader顺序地、逐块地读取日志文件解析物理记录头、校验 checksum并把分片kFirstType、kMiddleType、kLastType拼接起来还原出当初传给AddRecord的完整数据记录。下面是教程文档给出的、简化自db/db_impl.cc中DBImpl::RecoverLogFile(...)的重放代码// --- Simplified from db/db_impl.cc --- // Inside DBImpl::RecoverLogFile(...) // Create the log reader for the specific log file number std::string fname LogFileName(dbname_, log_number); SequentialFile* file; Status status env_-NewSequentialFile(fname, file); // ... check status ... // Set up reporter for corruption errors log::Reader::Reporter reporter; // ... initialize reporter ... log::Reader reader(file, reporter, true /*checksum*/, 0 /*initial_offset*/); // Read records one by one and apply them to a temporary MemTable std::string scratch; Slice record; WriteBatch batch; MemTable* mem new MemTable(internal_comparator_); mem-Ref(); while (reader.ReadRecord(record, scratch) status.ok()) { // record now holds a complete record originally passed to AddRecord // Parse the record back into a WriteBatch WriteBatchInternal::SetContents(batch, record); // Apply the operations from the batch to the MemTable status WriteBatchInternal::InsertInto(batch, mem); // ... check status ... // Update the max sequence number seen const SequenceNumber last_seq /* ... get from batch ... */; if (last_seq *max_sequence) { *max_sequence last_seq; } // Optional: If MemTable gets too big during recovery, flush it if (mem-ApproximateMemoryUsage() options_.write_buffer_size) { status WriteLevel0Table(mem, edit, nullptr); // Flush to SSTable mem-Unref(); mem new MemTable(internal_comparator_); mem-Ref(); // ... check status ... } } delete file; // Close the log file // ... handle final MemTable (mem) if not null ...逐步解释创建一个指向待恢复 WAL 文件.log的log::Reader。构造时传入checksumtrue启用校验和验证与initial_offset0从文件头开始读。代码循环调用reader.ReadRecord(record, scratch)record这个Slice指向日志中下一条完整逻辑记录的重组数据scratch一个临时字符串缓冲当记录跨多个块时供 Reader 使用。循环体内把record内容是一个序列化的WriteBatch解析回WriteBatch对象WriteBatchInternal::SetContentsWriteBatchInternal::InsertInto(batch, mem)把恢复出来的操作Put/Delete应用到内存MemTable持续追踪遇到的最新序列号max_sequence用于恢复后的VersionSet状态可选若恢复期间MemTable填满超过options_.write_buffer_size与正常运行一样就地刷写为 Level-0 SSTableWriteLevel0Table并新建一个空MemTable继续重放。直到ReadRecord返回false文件末尾或出现错误为止。ReadRecord 的分片组装状态机log::Reader::ReadRecord的实现负责读取块、定位头、校验 checksum并组合kFirstType、kMiddleType、kLastType分片。教程文档给出如下简化版// --- Simplified from db/log_reader.cc --- // Reads the next complete logical record. Returns true if successful. bool Reader::ReadRecord(Slice* record, std::string* scratch) { // ... skip records before initial_offset if necessary ... scratch-clear(); record-clear(); bool in_fragmented_record false; Slice fragment; // To hold data from one physical record while (true) { // Reads the next physical record (header data fragment) from the file blocks. // Handles reading across block boundaries internally. const unsigned int record_type ReadPhysicalRecord(fragment); // ... handle resyncing logic after seeking ... switch (record_type) { case kFullType: // ... sanity check for unexpected fragments ... *record fragment; // Got a complete record in one piece return true; case kFirstType: // ... sanity check for unexpected fragments ... scratch-assign(fragment.data(), fragment.size()); // Start of a new fragmented record in_fragmented_record true; break; case kMiddleType: if (!in_fragmented_record) { /* Report corruption */ } else { scratch-append(fragment.data(), fragment.size()); } // Append middle piece break; case kLastType: if (!in_fragmented_record) { /* Report corruption */ } else { scratch-append(fragment.data(), fragment.size()); // Append final piece *record Slice(*scratch); // Reassembled record is complete return true; } break; case kEof: return false; // End of log file case kBadRecord: // ... report corruption, clear state ... in_fragmented_record false; scratch-clear(); break; // Try to find the next valid record default: // ... report corruption ... in_fragmented_record false; scratch-clear(); break; // Try to find the next valid record } } }要点拆解ReadRecord在一个循环中反复调用内部辅助函数ReadPhysicalRecord。ReadPhysicalRecord未完整展示从文件中读取数据、解析 7 字节头、检查 CRC并返回记录类型与数据分片result它会自行处理块尾 trailer 的跳过与跨块读取。基于record_typeReadRecord的决策逻辑kFullType一条完整记录一次读齐直接返回kFirstType开始组装新记录——把数据拷入scratch置位in_fragmented_recordkMiddleType中间分片——若不在碎片组装状态则报告损坏否则追加到scratchkLastType收尾分片——追加后scratch即为完整记录返回kEof文件读完返回false结束重放kBadRecord/ default报告损坏、清空状态尝试寻找下一条有效记录继续这正是日志损坏后的跳过坏段继续恢复能力。scratch缓冲负责承载正在组装的碎片数据当记录跨多个块/多条物理记录时它充当临时拼接区。恢复流程总览如果发生过崩溃数据库启动时 WAL 的使用过程可用下图概括值得强调的是恢复过程中的两个关键判断对应 第四章DBImpl 中DBImpl::Open的恢复流程只重放需要恢复的日志DBImpl会扫描数据库目录找出比 MANIFEST 中记录的日志号更新的.log文件。这些日志代表上次关闭/崩溃前可能尚未刷写为 SSTable 的写入。干净关闭时没有相关日志也就无需重放。边重放边刷写如果 WAL 中累积的数据量超过write_buffer_size恢复过程会像正常运行一样把满的MemTable刷写为 Level-0 SSTable避免恢复期内存无限增长。源码级要点速查主题关键点文档/源码参考写入顺序WAL 落盘 → 可选 Sync → MemTable 更新 → 返回成功本文DBImpl::Write代码段log_-AddRecord/logfile_-Sync()/InsertInto物理块日志文件由固定大小块组成如 32KB块剩余空间不足kHeaderSize时补 trailer 换新块Writer::AddRecord中kBlockSize/block_offset_逻辑物理记录头7 字节checksum length RecordTypeEmitPhysicalRecord记录分片kFullType/kFirstType/kMiddleType/kLastTypeAddRecord与ReadRecord损坏处理checksum 校验失败 →kBadRecord→ 报告损坏并尝试找下一条有效记录ReadRecord状态机恢复重放RecoverLogFile循环ReadRecord→SetContents→InsertInto(mem)本文DBImpl::RecoverLogFile代码段与 WriteBatch 关系WAL 每条记录 一个序列化 WriteBatch整批原子、单次日志 I/O第五章WriteBatch与 DBImpl 关系DBImpl持有logfile_/logfile_number_/log_MemTable 切换时轮换新 WAL 文件第四章DBImpl与序列号关系恢复时追踪max_sequence用于重建 VersionSet 状态InternalKey 依赖 seq 排序第九章InternalKey DBFormat、第六章Version VersionSet总结Write-Ahead LogWAL是保证 LevelDB持久性durability的关键组件。通过把每次操作先追加写入磁盘上的 append-only 日志文件再应用到内存MemTable、最后才向用户确认写入LevelDB 保证了已确认的写入在任何崩溃场景下都不会丢失。核心要点回顾log::Writer负责把记录追加到当前 WAL 文件处理块block格式化与跨块分片fragmentation每条物理记录带 7 字节头checksum 长度 类型。log::Reader负责在恢复期间把记录从 WAL 文件读回逐块顺序读取、校验 checksum、把kFirstType/kMiddleType/kLastType分片重组为完整逻辑记录。恢复流程重放日志中的操作本质是重放序列化的 WriteBatch把崩溃时丢失的MemTable状态重建出来恢复期间若MemTable写满还会就地刷写为 Level-0 SSTable。WAL、MemTable 与 SSTable 协同工作WAL 为最新写入提供快速持久性MemTable 在内存中提供对这些最新写入的快速访问SSTable 为绝大部分数据提供持久化、有序的存储。理解 WAL 之后下一步可以学习这一切的总协调者——DBImpl看它如何统筹 WAL、MemTable、VersionSet 与后台压缩任务构成一个完整可用的数据库引擎。本系列文章由 AI Codebase Knowledge Builder 辅助生成更多章节见 LevelDB 教程索引。【免费下载链接】Tutorial-Codebase-KnowledgePocket Flow: Codebase to Tutorial项目地址: https://gitcode.com/gh_mirrors/tu/Tutorial-Codebase-Knowledge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考