ETCD历史数据清理
ETCD存储配置
- Etcd存储的默认空间配额为2G,在云端部署时,实测即使配置10G的数据卷,默认存储仍然仅可以使用2G,可见受到了默认参数的限制。
- 经查询,受到了quota-backend-bytes这个参数的限制,可将该参数扩大,以增加实际可用空间:
quota-backend-bytes=8388608000
- 官方建议最大更改设置改为8G,但是随着时间的累计,生产环境的etcd存储仍然会出现不够用的情况,此时不应再采取扩容的方式,而是应该进行数据压缩和数据清理,这样可以避免etcd服务的重启和报错,也可以清理掉旧的历史数据,从而减轻集群的数据量,保持服务的稳定使用。
ETCD存储空间清理
- ETCD存储数据对一个key的操作是append操作,对一个key的操作,是一个不断增加版本号的操作,存储起来。然后对这些历史key根据版本号进行压缩处理,一般业务场景中,不会用到key的历史数据,所需要的一般为当前key值。
请跟根据实际业务需求谨慎使用以下方式进行数据清理:
- 首先使用etcdctl命令行查询当前节点状态,返回信息中会显示当前节点的数据占用大小;
etcdctl endpoint status #展示当前节点状态信息
- 获取当前版本信息,赋值在变量内,也可以直接echo打印当前版本信息;
VS=$(etcdctl endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9].*')
- 将当前版本之前的版本全部压缩;
etcdctl compact $VS #将当前节点前的数据全部压缩
- 使用命令清理数据空间,会将上一步中压缩的数据全部清理,只保留当前版本最新key值;
etcdctl defrag --cluster #清理数据空间
- 再次使用命令行查询当前节点状态,查看数据大小,是否清理成功;
etcdctl endpoint status #展示当前节点状态信息
ETCD清理策略配置
以上方法为临时处理方式,对于生产环境这种长期使用的情况,建议配置自动清理策略更为方便和稳定,参考官方文档:link.
官方提供了另种配置方式:
- 按时间段来(配置开启,periodic):
每1/10个配置的时间段,执行一次压缩,压缩的数据是1/10个小时计算的。
- 按版本号(配置开启,reversion):
每5分钟执行一次:扫描现有key的所有latestVersion。压缩掉 latestVersion- retention之前的所有
具体配置例子如下:
- periodic:
-auto-compaction-mode: periodic #按时间段压缩
-auto-compaction-retention: 10h #保留10小时前的历史数据
- revision
-auto-compaction-mode: revision #按版本进行压缩
-auto-compaction-retention: 1000 #保留近1000个revision