ETCD使用中需要注意的问题--自动压缩--最大字节数--存储数据大小

数据库人生

已于 2023-08-19 16:00:04 修改

阅读量1.3k

点赞数

分类专栏： postgresql ha patroni 文章标签： etcd 数据库 linux

于 2023-08-19 15:43:01 首次发布

原文链接：https://www.cnblogs.com/lgj8/p/13631426.html

版权

postgresql ha patroni 专栏收录该内容

14 篇文章 ¥19.90 ¥99.00

订阅专栏

本文探讨了在ETCD实际生产环境中遇到的问题，如数据存储限制和自动压缩配置。强调了`--auto-compaction-retention`、`--max-request-bytes`和`--quota-backend-bytes`参数的重要性。建议在初始化时设定好这些参数，以确保集群稳定性，避免数据达到2GB后无法写入。官方推荐值和业务需求应结合考虑，例如将`--max-request-bytes`设置为10MB以保持集群稳定。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

我们在实际生产中使用ETCD存储元数据，　起初集群规模不大的时候元数据信息不多没有发现什么问题。　随着集群规模越来越大问题逐渐暴露了

有些实际的配置还是需要在初始化的时候就研究确定

–auto-compaction-retention

由于ETCD数据存储多版本数据，随着写入的主键增加历史版本需要定时清理，　默认的历史数据是不会清理的，数据达到2G就不能写入，必须要清理压缩历史数据才能继续写入；

所以根据业务需求，在上生产环境之前就提前确定，历史数据多长时间压缩一次；　我们的生产环境现在升级后是默认一小时压缩一次数据。这样可以极大的保证集群稳定，减少内存和磁盘占用

–max-request-bytes

etcd Raft消息最大字节数，ETCD默认该值为1.5M; 但是很多业务场景发现同步数据的时候1.5M完全没法满足要求，所以提前确定初始值很重要；　由于1.5M导致我们线上的业务无法写入元数据的问题，

我们紧急升级之后把该值修改为默认32M,但是官方推荐的是10M，大家可以根据业务情况自己调整

#最好按照官方的默认限制来储存，单个value不要超过10M，只要不超过10M生产环境就会很稳定，一旦超过10M集群就会变的不稳定；

–quota-backend-bytes

ETCDdb数据大小，默认是２G,当数据达到２G的时候就不允许写入，必须对历史数据进行压缩才能继续写入；　参加1里面说的，我们启动的时候就应该提前确定大小，官方推荐是8G,这里我们也使用8G的配置

可以参考 etcd doc
https://etcd.io/docs/v3.3/op-guide/configuration/
https://etcd.io/docs/v3.3/op-guide/maintenance/#auto-compaction
https://etcd.io/docs/v3.3/op-guide/maintenance/#defragmentation
https://etcd.io/docs/v3.3/op-guide/maintenance/#space-quota

etcd 3.3.3版本以后的自动压缩方式：
#每5分钟自动压缩"latest revision" - 1000
--auto-compaction-mode=revision --auto-compaction-retention=1000
#每1小时自动压缩并保留12小时窗口
--auto-compaction-mode=periodic --auto-compaction-retention=12h