4. 自动压缩配置：详解 --auto-compaction-retention 参数
etcd 的自动压缩功能通过 --auto-compaction-retention 启动参数控制，支持两种独立的压缩模式：基于时间和基于版本号。运维人员只需在启动时指定该参数，etcd 便会周期性地检查并执行压缩，无需人工介入。
4.1 两种压缩模式对比
| 模式 | 参数值示例 | 触发条件 | 适用场景 |
|---|---|---|---|
| 基于时间 | 1h、24h、72h |
保留最近 N 小时内的所有历史版本，超出时间范围的旧版本被压缩 | 常规运维，按时间窗口保留数据，适合大多数生产集群 |
| 基于版本号 | 1000、5000、10000 |
保留最近 N 个连续版本（revision），超出数量的旧版本被压缩 | 对版本数量敏感、需要精确控制历史版本深度的场景 |
关键区别：时间模式关注“多久之前”，版本模式关注“多少个版本”。如果写入速率不稳定，时间模式更直观；如果写入速率恒定，两种模式效果接近。
4.2 基于时间的自动压缩
当参数值包含时间单位后缀（h、m、s）时，etcd 启用时间模式。例如：
# 保留最近 1 小时内的所有历史版本
etcd --auto-compaction-retention=1h
# 保留最近 24 小时内的所有历史版本
etcd --auto-compaction-retention=24hetcd 内部会定期（默认每 5 分钟）检查当前时间与历史事件时间戳的差值，将超出保留窗口的旧版本标记为可压缩。压缩操作本身是异步的，不会阻塞读写请求。
注意事项：时间模式依赖 etcd 集群的时钟同步。如果节点间时钟偏差过大，可能导致部分节点提前或延迟执行压缩。建议在生产环境部署 NTP 服务。
4.3 基于版本号的自动压缩
当参数值为纯数字（无时间单位后缀）时，etcd 启用版本号模式。例如：
# 保留最近 1000 个版本
etcd --auto-compaction-retention=1000
# 保留最近 5000 个版本
etcd --auto-compaction-retention=5000etcd 会维护一个全局单调递增的 revision 计数器。每次写入（put/delete）都会生成一个新的 revision。当当前 revision 与已压缩的 revision 之差超过设定值时，触发压缩。
4.4 自动压缩工作流程
下图展示了 etcd 自动压缩的核心决策流程：
4.5 运行时动态调整
除了启动参数，etcd 还支持通过 API 在运行时动态修改压缩策略，无需重启集群：
# 切换到时间模式，保留最近 2 小时
etcdctl compaction-retention set 2h
# 切换到版本模式，保留最近 3000 个版本
etcdctl compaction-retention set 3000
# 查询当前压缩配置
etcdctl compaction-retention get
最佳实践：建议在集群初始化时通过启动参数设置默认策略，后续根据业务变化通过 API 动态调整。生产环境推荐使用时间模式（如
24h），兼顾数据可回溯性和存储成本。
4.6 参数选择决策树
以下决策树帮助运维人员快速选择适合的压缩模式：
- 业务是否需要精确回溯到某个时间点？ → 是 → 选择时间模式（如
24h） - 业务是否需要精确控制历史版本数量？ → 是 → 选择版本模式（如
5000） - 写入速率是否高度波动？ → 是 → 优先选择时间模式，避免版本模式在写入高峰时压缩过于激进
- 集群是否跨多个时区或时钟不同步？ → 是 → 优先选择版本模式，避免时间偏差导致压缩异常
默认值：如果未设置
--auto-compaction-retention，etcd 默认不启用自动压缩。此时历史版本会无限累积，直到存储空间耗尽。生产环境务必显式配置此参数。