数据文件为什么会膨胀
数据后端采用多版本存储并保留历史修订，频繁写入会产生大量旧版本与磁盘碎片，文件体积持续增长但实际数据量并没有那么大。回收空间需要两步：先压缩掉不再需要的历史修订，再整理碎片把空间真正还给文件系统。整理过程会阻塞该成员的读写。
基本信息
| 操作对象 | 自建集群的数据后端成员 |
|---|---|
| 前置条件 | 需要证书与访问接口地址 |
| 两个步骤 | 压缩历史修订、整理碎片 |
| 影响范围 | 整理期间该成员短暂不可用 |
| 执行策略 | 逐成员进行，避开业务高峰 |
典型使用场景
- 数据目录持续增长，磁盘水位告警
- 写入密集的集群出现请求延迟上升
- 例行维护时回收空间，控制文件体积
- 节点磁盘容量有限，需要定期整理
- 迁移或扩容前评估各成员数据量
查看成员状态
查看成员状态
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint status --write-out=table # 关注数据文件大小与修订号压缩与整理
压缩与整理
REV=$(etcdctl --endpoints=https://127.0.0.1:2379 endpoint status --write-out=json | jq -r '.[0].Status.header.revision')
etcdctl --endpoints=https://127.0.0.1:2379 compact $REV # 压缩历史修订
etcdctl --endpoints=https://127.0.0.1:2379 defrag # 整理碎片回收空间
etcdctl --endpoints=https://127.0.0.1:2379 endpoint status --write-out=table # 核对体积变化状态字段读法
| 字段 | 含义 | 关注点 |
|---|---|---|
| 数据文件大小 | 后端文件占用 | 持续增长说明需要整理 |
| 修订号 | 当前最新修订 | 压缩时作为目标值 |
| 成员标识 | 成员唯一标识 | 确认操作对象正确 |
| 健康状态 | 成员是否可用 | 整理前确认集群整体健康 |
压缩只是标记历史修订可回收，文件大小不会立即下降；真正的空间回收发生在整理阶段。两个步骤需要按顺序执行，只做其中一个效果有限。
整理属于就地操作，执行期间会占用较多磁盘输入输出，数据目录所在磁盘的剩余空间与性能都会影响耗时。操作前确认磁盘健康度与空余容量。
整理期间该成员会阻塞读写请求。多成员集群必须逐个执行，同时操作多个成员会让集群失去多数派，造成整体不可写。