我们在实际生产中使用ETCD存储元数据,起初集群规模不大的时候元数据信息不多没有发现什么问题。随着集群规模越来越大问题逐渐暴露了。
- --auto-compaction-retention
由于ETCD数据存储多版本数据,随着写入的主键增加历史版本需要定时清理,默认的历史数据是不会清理的,数据达到2G就不能写入,必须要清理压缩历史数据才能继续写入;
跟具官方介绍有两种自动压缩配置:
在3.3.3以后的版本中,--auto-compaction-mode=revision --auto-compaction-retention=1000 每5分钟自动压缩"latest revision" - 1000;--auto-compaction-mode=periodic --auto-compaction-retention=12h 每1小时自动压缩并保留12小时窗口。
- --max-request-bytes
Etcd Raft消息最大字节数,ETCD默认该值为1.5M; 但是很多业务场景发现同步数据的时候1.5M完全没法满足要求,所以提前确定初始值很重要。官方推荐的是10M,大家可以根据业务情况自己调整。
- --quota-backend-bytes
ETCD db数据大小,默认是2G,当数据达到2G的时候就不允许写入,必须对历史数据进行压缩才能继续写入;我们启动的时候就应该提前确定大小,官方推荐是8G配置。
我们的配置调整,在etcd.service文件里面加入下面内容:
--auto-compaction-mode=revision \
--auto-compaction-retention=1000 \
--max-request-bytes=$((32*1024*1024)) \
--quota-backend-bytes=$((8*1024*1024*1024))
即:--max-request-bytes=32M,--quota-backend-bytes=8G
defrag
在自动压缩keys空间后系统数据库会产生碎片,碎片依旧占用系统存储空间,可以使用defrag命令清理。
$ etcdctl defrag
Finished defragmenting etcd member[127.0.0.1:2379]
查看数据库占用空间
etcdctl --write-out=table endpoint status
网友评论