【etcd】Compaction、Defrag 与容量：quota、alarm 与 SLO
内容提要
本文介绍etcd v3.5.33的容量管理机制：Compaction删除历史revision但不缩文件，Defrag回收bbolt文件空洞，quota默认2GiB触发NOSPACE alarm后拒绝写入。运维需先compact再defrag，注意auto-compaction保留窗口与Watch续传的SLO耦合，避免过短导致ErrCompacted风暴。
延伸解读
Compaction 与 Defrag 的先后顺序
Compaction 只删除历史 revision，不缩小文件；Defrag 才回收 bbolt 文件空洞。若 quota 触顶先 defrag，空洞未产生，效果有限。正确顺序是先 compact 到目标 rev，再在低峰期对单 member 执行 defrag，避免全集群同时锁 store。
Auto-compaction 保留窗口与 Watch 续传的权衡
auto-compaction 保留窗口过短，会导致客户端从旧 revision 续传 Watch 时触发 ErrCompacted 风暴。保留窗口应至少覆盖客户端最大断线时间与 apiserver resync 周期。工程上需根据集群写入率和 Watch 延迟实测调整，而非依赖默认值。
Quota 触顶后的处理路径
quota 默认 2GiB，触顶后触发 NOSPACE alarm 并拒绝写入。解除 alarm 必须先通过 compact 和 defrag 真正降低 db Size，再执行 etcdctl alarm disarm。注意 mmap 余量：QuotaBackendBytes 的 10% 用于 MmapSize，因此实际可用空间略小于 quota。
Defrag 的代价与观测
Defrag 会持锁阻塞读写，导致短窗口内延迟上升。可通过 Prometheus 指标 etcd_mvcc_db_total_size_in_use_bytes 与 etcd_mvcc_db_total_size_bytes 的差值判断空洞大小，差值大时 defrag 效果明显。建议在低峰期单 member 执行，并与 snapshot 备份窗口错开。
Q&A
etcd中compaction和defrag有什么区别？
compaction是删除历史revision，释放MVCC历史版本占用的逻辑空间，但不会缩小bbolt文件大小；defrag是物理重组bbolt文件，回收compaction后留下的文件空洞，从而减小文件大小。
etcd默认的quota大小是多少？超过后会发生什么？
etcd默认的quota大小是2GiB（通过--quota-backend-bytes=0启用）。超过quota后，写入请求会被拒绝，并触发NOSPACE alarm，集群进入只读状态。
etcd触发NOSPACE alarm后如何恢复写入？
需要先执行compaction删除历史revision，再执行defrag回收文件空洞，降低数据库实际大小，然后使用etcdctl alarm disarm解除告警，恢复写入。
etcd的auto-compaction有哪两种模式？分别如何工作？
auto-compaction有两种模式：periodic模式按时间窗口（如1小时）保留数据，每period/10采样revision，保留期满后compact最早采样点；revision模式保留最近N个main revision。
etcd中defrag操作会阻塞读写吗？
是的，defrag会持有batchTx、mu和readTx锁，阻塞并发读写操作，因此建议在低峰期对单个member执行，避免影响集群性能。
etcd中quota的Cost估算包括哪些开销？
Put操作的开销为256 + len(key) + len(value)；Txn操作取Success/Failure分支中较大一侧的Put成本之和；LeaseGrant开销为64。
etcd中auto-compaction保留窗口过短会有什么风险？
保留窗口过短会导致Watch从旧revision续传时失败，出现ErrCompacted错误，可能引发客户端全量同步，造成ErrCompacted风暴。
