我们在实际生产中使用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数据大小，默认是２G,当数据达到２G的时候就不允许写入，必须对历史数据进行压缩才能继续写入；我们启动的时候就应该提前确定大小，官方推荐是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
