4. etcd 磁盘空间模型：数据目录结构、WAL 日志、Snapshot 快照、数据压缩与碎片整理

etcd 作为云原生日志平台的核心元数据存储，其磁盘空间模型直接决定了集群的稳定性与运维成本。理解 etcd 的数据目录结构、WAL 日志、Snapshot 快照、数据压缩与碎片整理机制，是进行磁盘空间瓶颈分析的前提。

4.1 数据目录结构

etcd 的数据目录通常由 --data-dir 参数指定，默认路径为 ${name}.etcd/。该目录下包含多个关键子目录和文件，各自承担不同的持久化职责：

4.2 WAL 日志：写入的第一道防线

WAL（Write-Ahead Log）是 etcd 保证数据持久性的核心机制。所有写入操作必须先写入 WAL 日志，然后才能应用到内存状态机。WAL 日志以段（segment）为单位存储，每个段文件默认最大 64MB。

• 写入流程： 客户端请求 → Raft 提案 → 写入 WAL → 提交到状态机 → 返回响应。
• 文件命名： WAL 文件以 ${seq}-${index}.wal 格式命名，例如 0000000000000001-0000000000000000.wal。
• 磁盘占用： 在日志平台高写入场景下，WAL 目录每小时可能产生数 GB 数据。如果快照生成不及时，旧 WAL 文件无法被清理，磁盘空间将迅速耗尽。

4.3 Snapshot 快照：压缩与回收的基石

Snapshot 是 etcd 对当前状态机数据的完整快照，用于压缩 WAL 日志和加速节点恢复。etcd 通过 --snapshot-count 参数控制快照生成频率（默认 100,000 次提交）。

快照生成后，etcd 会执行以下操作：

1. 将当前 BoltDB 数据写入 member/snap/ 目录。
2. 删除所有早于该快照的 WAL 文件。
3. 更新快照元数据，记录当前已应用的 Raft 索引。

快照文件本身也会占用磁盘空间，但远小于被清理的 WAL 日志总量。快照文件通常为 BoltDB 数据库文件的压缩副本，大小在数百 MB 到数 GB 之间。

4.4 数据压缩与碎片整理

etcd 使用 BoltDB 作为底层存储引擎。BoltDB 是一个基于 B+ 树的嵌入式键值数据库，支持事务和 ACID 特性。然而，BoltDB 存在一个显著问题：删除操作不会立即释放磁盘空间，而是标记为“空闲页”，导致数据库文件持续膨胀。

4.4.1 数据压缩（Defragmentation）

etcd 提供了 etcdctl defrag 命令，用于对 BoltDB 文件进行碎片整理。该命令会重新组织数据库文件，回收空闲页，释放磁盘空间。

• 触发方式： 手动执行 etcdctl defrag 或通过 API 调用。
• 影响： 压缩期间 etcd 会暂停处理读写请求（v3.4 及之前版本），v3.5+ 支持在线压缩（仅影响单个成员）。
• 频率建议： 在日志平台场景下，建议每 24-48 小时执行一次压缩，或当数据库文件大小超过实际数据量 2 倍时触发。

4.4.2 自动压缩（Auto Compaction）

etcd 支持自动压缩历史版本，避免历史版本堆积导致数据库膨胀。自动压缩通过 --auto-compaction-retention 参数配置，支持两种模式：

自动压缩仅标记历史版本为可回收，不会立即释放磁盘空间。实际空间回收仍需通过 defrag 操作完成。

4.5 磁盘空间模型总结

etcd 的磁盘空间模型可以概括为以下关键公式：

总磁盘占用 = WAL 日志大小 + Snapshot 快照大小 + BoltDB 数据库大小 + 其他元数据

WAL 日志大小 ≈ 写入速率 × (snapshot-count / 提交频率)
BoltDB 数据库大小 ≈ 有效数据量 × (1 + 碎片率)
碎片率 = (文件大小 - 有效数据大小) / 有效数据大小

在日志平台场景下，由于持续高写入和频繁的键值删除/更新操作，碎片率可能高达 100%-200%。因此，定期执行自动压缩和碎片整理是保障 etcd 磁盘空间健康的核心手段。