etcd 数据库越用越大：compaction 滞后与 defrag 缺失的根因及一套可复现的收敛方案

结论先行

etcd 数据目录「只涨不缩」，绝大多数不是写入量大，而是两件事没人管：一是 compaction 没跟上（历史 revision 一直堆着），二是 defrag 从未执行（被删除的 revision 只标记不回收，物理空间不释放）。把这两条做成定时任务并监控到位，一个 50G 的 etcd 成员通常能收敛到个位数 G。下面按现象、根因、做法、坑、清单五段讲。

一、现象：一个 3 节点集群，单成员数据目录 9 天从 8G 涨到 52G

去年 10 月，我们一个 3 节点 etcd 3.5.9 集群（承载 K8s 1.28 控制面，约 4 万对象、2200 个 Pod），单成员 /var/lib/etcd 在 9 天内从 8G 一路涨到 52G，磁盘水位告警。etcdctl endpoint status 显示 DB Size 52G，但 etcdctl endpoint status --write-out=table 里 Leader 正常、Errors 为空——服务完全健康，纯是磁盘在吃。更反直觉的是：我们没有任何配置变更，也没有人批量导入，写入 QPS 一直是个位数。

二、根因：compaction 与 defrag 是两件事，且默认都不自动做

etcd 的 MVCC 存储模型里，每个 key 的每次修改都生成一个新的 revision（全局单调递增）。compaction 的作用是「把某个 revision 之前的历史版本标记为可删除」，但它只是打标记，不回收物理空间；真正释放空间的是 defrag（重写整个 BoltDB 文件、剔除不可见的 revision）。

关键默认值（这是坑的根源）：

• etcd 默认不自动 compaction：不显式传 --auto-compaction-mode 时，历史 revision 全部保留。K8s 用 etcd 时虽然 controller-manager 会周期性 compact（默认 --compaction-interval=5m），但它只 compact、不 defrag。
• etcd 默认不自动 defrag：defrag 需要在线加锁重写，官方认为不该由服务端自动触发，必须运维显式执行 etcdctl defrag。

所以「只 compact 不 defrag」= 垃圾只标记不回收，物理文件照涨不误。我们的复盘确认：9 天里 compaction 一直在做（K8s 每 5 分钟一次），但 defrag 一次没跑过。

三、具体做法：监控 + 定时 compaction/defrag + 快照兜底

1. 先量化「可回收空间」，别盲目 defrag：

# 看 DB Size 与可压缩空间（etcd 3.5 支持 --debug-flags 已弃用，改用 member 日志）
etcdctl endpoint status --cluster --write-out=table
# 直接看成员日志里的 compaction 进度；或用
etcdctl defrag --cluster --debug-logs 2>&1 | grep -i "defragment"

2. 给非 K8s 用途的 etcd（自建业务 etcd）补上自动 compaction：

etcd --auto-compaction-mode=periodic --auto-compaction-retention=2h
# K8s 场景则确保 apiserver 的 controller-manager 活着：
#   --compaction-interval=5m（默认即 5m，别设成 0，0 表示关掉）

3. 定时 defrag（核心动作，逐成员执行，避免同时打满）：

# 逐节点执行，每次只 defrag 一个成员，间隔 5s，降低锁竞争
for ep in 10.0.0.11:2379 10.0.0.12:2379 10.0.0.13:2379; do
  ETCDCTL_API=3 etcdctl --endpoints=$ep defrag && sleep 5
done

我们对那个 52G 的成员执行 defrag，单成员耗时约 4 分钟，DB Size 从 52G 降到 6.3G，磁盘水位从 91% 回落到 18%。

4. 兜底：defrag 前留快照（defrag 是重写，期间异常掉电有风险）：

ETCDCTL_API=3 etcdctl --endpoints=10.0.0.11:2379 \
  snapshot save /backup/etcd-$(date +%F).db
# 恢复时：
etcdctl snapshot restore /backup/etcd-2024-10-01.db \
  --data-dir=/var/lib/etcd-new --name=etcd0 --initial-cluster=...

5. 把「DB Size 与磁盘水位」纳入告警：DB Size 单成员 > 20G 或数据盘水位 > 70% 即告警，别等打满。

四、踩过的坑 / 反直觉之处

1. defrag 有锁、会短暂阻塞写入：在线 defrag 期间该成员对新写入持锁，单成员 4 分钟意味着这几秒到几十秒内写入变慢。所以别 3 个成员同时 defrag，要逐台、间隔执行；高峰期（批量发版）避开。
2. compaction 了但空间没掉，别怀疑 compaction 没生效——是 defrag 没做。这是最容易被误判的点：很多人盯着 compaction 调参，其实差的是 defrag。
3. --auto-compaction-retention 设太短（如 10m）会放大读放大：保留窗口太短，历史 revision 被快速回收，对依赖 revision 范围读（etcdctl get --rev）或 K8s 的 watch 回放不友好，我们最终定在 2h，是磁盘与读回放的折中。
4. 快照 restore 会换 member ID：restore 后成员 ID 变了，集群证书里的 SAN / 节点身份要同步，否则新集群认不出旧 peer，直接起不来。

五、结论与可复用清单

• 记住分工：compaction 管「标记可删」，defrag 管「真正回收」；K8s 只帮你做前者，defrag 永远是你自己的活。
• 默认值陷阱：etcd 默认不自动 compact 也不自动 defrag，自建 etcd 务必显式配 --auto-compaction-mode=periodic --auto-compaction-retention=2h。
• 操作顺序：snapshot save → 逐成员 defrag（间隔 5s）→ 复查 endpoint status 的 DB Size。
• 告警阈值：单成员 DB Size > 20G 或数据盘 > 70% 告警；defrag 后应能从 52G 级收敛到个位数 G，做不到就说明还有别的写入源。
• 保留窗口：retention 别贪短，2h 是磁盘与读回放经验的折中，可按业务读模式调。

一句话：etcd 越用越大，9 成是 defrag 缺位；把 defrag 做成受控的定时动作，是性价比最高的一次运维。