etcd 数据压缩

漂泊的孤狼

已于 2023-12-06 14:20:06 修改

阅读量1k

点赞数

文章标签： etcd 数据库

于 2023-02-24 18:30:11 首次发布

本文链接：https://blog.csdn.net/weixin_42323738/article/details/129205786

版权

当etcd的默认存储空间不足时，可以通过数据压缩和碎片化整理来优化，而不是扩容。在etcd版本3.4.14下，使用etcdctl工具进行endpoints指定的3个节点同时压缩，然后执行defrag命令进行碎片化整理，成功将dbsize从587M减至115M，宿主机磁盘空间也显著减少。最后，检查并解除alarms以确保集群健康状态。

摘要由CSDN通过智能技术生成

一、使用场景

etcd默认的生产存储为2G，通常我们会更改为8G，但是当我们的生产环境的etcd存储仍然不够用的情况下，我们一般不再采取扩容，而是进行数据压缩的形式，一则可以避免etcd的重启，二则可以清理掉历史的旧日志，从而减轻集群的数据量，保持进群稳定。备注：次测试在etcd3的情况下进行测试

二、操作步骤

1) 查看etcdctl的版本号
[root@etcd-test1 ~]# etcdctl version

etcdctl version: 3.4.14

API version: 3.4

2)操作步骤如下

alias ectl="ETCDCTL_API=3 etcdctl --endpoints=https://172.20.30.75:2379,https://172.20.30.231:2379,https://172.20.30.245:2379 --cacert=/etc/kubernetes/pki/etcd/ca.pem --cert=/etc/kubernetes/pki/etcd/etcd.pem --key=/etc/kubernetes/pki/etcd/etcd-key.pem"


起始数据大小：看磁盘682M，通过命令看db size 587M
1、endpoints指定3个节点同时压缩，再碎片化整理
1）rev=`ectl endpoint status -w json | egrep -o '"revision":[0-9]+' |egrep -o '[0-9]+'|uniq`
2）ectl compact $rev
3）ectl endpoint status -w table 这个时候看db size发现数据可能没有发生变化，看宿主机磁盘目录数据量也没有发生变化，不要慌，你的数据已经压缩了，还需要执行第四步整理才行
4）ectl defrag
5）ectl endpoint status -w table 这个时候看db size已经由原来的587M变成了115M，看宿主机的磁盘，由原来的682M变成了232M
6）ectl alarm list 告警检查
7) ectl alarm disarm 取消告警，这一步一定要做，否则集群的状态是不健康,导致集群无法使用
结论：db size变成115M，主机磁盘变成232M