Etcd 基础维护

Posted 2023-04-19

参考技术A 本文所有命令均在 TLS 环境下运行，如需参考，请自行更改为您的环境（节点IP，证书路径），无证书环境请删除证书相关指令

本文所有命令均在 etcdctl 默认api ，即 etcd api v2 下操作，v3 指令略有改动可能不匹配，详情请查阅官方文档： https://etcd.io/docs/

查看版本

查看 Etcd 暴露出来的 prometheus 指标，在 prometheus 对其监控时可调用

查看 etcd、etcd api v2 版本

查看 etcd、etcd api v3 版本

查询节点 ID

删除节点，如删除 Eecd3

修改配置文件 etcd.conf，修改参数 ETCD_INITIAL_CLUSTER 并移除节点信息，重启etcd服务

1）在群集中删除故障节点
在任意一 etcd 节点服务器查询该节点 ID，通过ID删除故障节点，操作步骤如下
删除目标节点的数据

2）编辑目标节点配置文件，将 --initial-cluster-state值改为 existing （否则会生成新的ID，与原ID不匹配将无法加入集群）

3）加入节点至集群，需输入目标节点的 etcd name 和 PEER_URLS

4）启动目标节点 etcd 服务

5）查看集群健康状态

停止 Etcd 服务

备份并删除当前 Etcd 数据

注意：此方法恢复数据可能不完整，仅建议极端环境下使用，常规数据恢复请使用快照

https://blog.csdn.net/ccy19910925/category_7590496.html

为啥etcd社区建议db大小不超过8G

参考技术A db大小会对那些方面造成影响:

treeIndex模块维护了用户key与boltdb key的映射关系,boltdb的key、value有包含了构建treeIndex的所需的数据,etcd启动的时候,会启动不同角色的
goroutine并完成treeIndex构建。

遍历boltdb获取所有key-value的数据,并将其反序列化成etcd的mvccpb.KeyValue结构。核心原理是基于etcd存储在boltdb中的key数据有序性,按版本号
从1开始批量遍历,每次查询1000条key-value记录,直到查询数据为空。

从主goroutine获取mvccpb.KeyValue数据,基于key、版本号、是否带删除表示等信息,构建keyIndex对象,插入到treeIndex模块的B-tree中。

etcd启动时只有一个构建treeIndex的goroutine。

etcd启动时,调用boltdb Open API的时候,设置了mmap的MAP_POPULATE flag,告诉内核预读文件,将db文件内容全部从磁盘加载到物理内存中
(通过mmap机制将db文件映射到内存中)。如果节点内存小于treeIndex内存之和,会触发缺页中断,导致读延时抖动、QPS下降。

boltdb事务提交的四个核心流程:B+ tree的重平衡、分裂,持久化dirty page、持久化freelist以及持久化meta data。

事务提交延时抖动的原因主要是在B+Tree树的重平衡和分裂过程中,需要从freeList中申请若干连续的page存储数据,或者释放空闲个的freelist。

freeList后端实现在boltdb中是array。如果db文件较大,又存在大量的碎片空闲页,很可能导致超时。同时事务提交过程中,也可能会释放若干个page给
freelist,因此需要合并到freelist的数组中,此操作时间复杂度是O(NlogN)。为了优化boltdb事务提交的性能,etcd实现了基于HashMap来管理freelist。
通过引入三个map数据结构(freemaps的key是连续的页数, value是以空闲页的起始页pgid集合,forwardmap和backmap用于释放的时候快速合并页),
将申请和释放时间复杂度降低到O(1),同时支持事务提交时,不持久化freelist,而是通过重启时扫描page重建,以提升etcd写性能、降低db大小。

那些expensive read请求会导致etcd不稳定性:

快照会影响db备份文件生成速度、Leader发送快照给Follower节点的资源开销、Follower节点通过快照重建恢复的速度。