11 | 压缩：如何回收旧版本数据？

唐聪



该思维导图由 AI 生成，仅供参考

你好，我是唐聪。
今天是大年初一，你过年都有什么安排？今年过年对我来说，其实是比较特别的。除了家庭团聚走亲访友外，我多了一份陪伴。感谢你和我在这个专栏里一块精进，我衷心祝你在新的一年里平安喜乐，万事胜意。
这节课是我们基础篇里的最后一节，正巧这节课的内容也是最轻松的。新年新气象，我们就带着轻松的心情开始吧！
在07里，我们知道 etcd 中的每一次更新、删除 key 操作，treeIndex 的 keyIndex 索引中都会追加一个版本号，在 boltdb 中会生成一个新版本 boltdb key 和 value。也就是随着你不停更新、删除，你的 etcd 进程内存占用和 db 文件就会越来越大。很显然，这会导致 etcd OOM 和 db 大小增长到最大 db 配额，最终不可写。
那么 etcd 是通过什么机制来回收历史版本数据，控制索引内存占用和 db 大小的呢？
这就是我今天要和你分享的 etcd 压缩机制。希望通过今天的这节课，能帮助你理解 etcd 压缩原理，在使用 etcd 过程中能根据自己的业务场景，选择适合的压缩策略，避免 db 大小增长失控而不可写入，帮助你构建稳定的 etcd 服务。
整体架构
在了解 etcd 压缩模块实现细节前，我先给你画了一幅压缩模块的整体架构图。从图中可知，你可以通过 client API 发起人工的压缩 (Compact) 操作，也可以配置自动压缩策略。在自动压缩策略中，你可以根据你的业务场景选择合适的压缩模式。目前 etcd 支持两种压缩模式，分别是时间周期性压缩和版本号压缩。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文深入介绍了etcd压缩机制的工作原理和实际操作，主要围绕etcd中的压缩模块展开讨论。首先详细介绍了压缩特性初体验，包括发起压缩操作以及压缩命令的注意事项。然后分别介绍了周期性压缩和版本号压缩模式的工作原理和适用场景。文章还解释了压缩任务的执行流程，包括压缩treeIndex模块中的历史版本、清理已删除的版本以及删除boltdb中废弃的历史版本数据。此外，文章还解释了压缩后db大小不减少的原因，以及boltdb管理空闲页的方式。最后，文章提出了思考题，引发读者对压缩与碎片整理的区别以及优化方案的思考。整体来看，本文内容涵盖了etcd压缩机制的核心工作原理和实际操作，对读者了解如何回收旧版本数据具有一定的参考价值。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《etcd 实战课》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(17)

最新
精选

云原生工程师
新年与老师一块精进，新年快乐，牛年一起旺旺旺。
作者回复: 谢谢，新年快乐，祝牛年升职加薪
2021-02-13

7
不二
老师好，有一个学习方面的疑问请教一下：我在工作中大量使用到kubernetes，算是比较了解，但是etcd确实没有深入。专栏从第一讲开始，每一讲的内容我都看得极其吃力，甚至完全看不懂，是不是缺少了哪一整块的先验知识？期待得到你的回复！
作者回复: 感谢你的提问，平时有使用过etcd吗？比如基本的etcdctl工具，了解下常见的命令，下载etcd二进制文件，本地启动一个etcd集群。基础篇每讲都有不少的案例，建议你实际动手执行下，很多东西你亲自去体验下，就有不一样的收获。专栏面向的对象包括初学者、有一定的基础的、有比较丰富经验的同学，每讲本身已经非常长了，受限于篇幅，因此很多网上一搜索的就能找到的资源，比如etcdctl使用、etcd集群搭建我就没介绍了，不过在后面专栏结束后，我考虑增加个入门篇，更加通俗易懂的，帮助没实际使用etcd的同学们快速上手。对kubernetes比较了解可以看看19和20会不会让你感觉更加亲切点。最后，每讲有什么疑问，可直接留言提问哈，没事的，不用担心问题是否简单，说不定其他入门的同学也能遇到。最近专栏还在定时更新阶段，非常忙，可能评论回复没那么快，定时更新结束后，我会定时抽空回答大家问题哈。
2021-03-08
2
4
八台上
想问一下如果不同的etcd server配置的auto compact 策略不一样以谁为准呢
作者回复: 有趣的问题，各个节点都会发起compact请求，etcd会记录已压缩的最大版本号，如果其他节点发起的compact版本号小于它，就直接返回ErrCompacted了。
2021-09-26
2
3
八台上
还有一个问题就是 defrag 的时候是不是服务不可用呀？如果是什么时机defrag 呢
作者回复: 嗯，defrag期间会持有boltdb事务锁导致读写超时，一般情况下不需要defrag的，只有当未配置compact策略或配置的策略非常不合理、以及线上突发大规模写入等场景下导致db文件非常大的时候才需要执行defrag。
2021-09-26

2
海阔天空
思考题的答案什么是可以统一给出呀
作者回复: 感谢支持，最近项目和家庭事情比较多，思考题答案我将尽快在周末抽空补充好（预计9月份）
2021-07-15

1
types
如果是etcd 集群，每个节点都配置了自动压缩策略，每个节点都会产生Compact请求吗？
作者回复: 嗯，etcd有记录已压缩最大的版本号，不会重复压缩。
2021-10-10


八台上
想问一下相当于没有自动清理碎片的配置是吗所以如果自动压缩策略和写入频率配合不好的话 db文件是会膨胀的？
作者回复: 你好，你应该是指压缩吧，默认没开启历史数据压缩功能，一般情况下只要你不保留太久(比如6h以上)，写入不要太频繁，db大小会保持稳定的。碎片整理是指defrag命令，它的核心原理是遍历老db数据，重新写入到一个新的db文件，使其更紧凑，但这个过程会影响etcd可用性。一般生产环境下不需要执行defrag命令，除非写入大量数据后，又删除了数据，db文件特别大。
2021-08-23


奕
etcd 的配置参数只能在启动的时候写到后面吗？不能用统一写到配置文件中？
作者回复: 都可以的哈
2021-02-28
2

写点啥呢
请问老师，基于版本号压缩中的版本号是etcd的全局单调递增的revision吧，这种方式下每个key保留的历史版本应该是不同的，比如A是昨天修改过10次，B是最近修改了10次，此时压缩可能B会保留多个历史版本而A可能只保留当前版本，不知道这样理解是否正确？那么如果是这样，有没有办法让etcd压缩能对每个key均匀保留历史版本，比如指定每个key最少保留2个版本？谢谢老师
2021-02-26
1
6
Geek_cb2b43
压缩的第一项任务中克隆B+tree，是如何保两份数据一致的呢？即如果在此期间B+tree出现了分裂，原来的记录可能发生了变化
2021-02-13
2
4

收起评论