https://www.cnblogs.com/yanshicheng/p/13436485.html

官方文档：https://etcd.io/docs/v3.4/op-guide/maintenance/

1.介绍

ETCD是一个分布式的、可靠的KV存储，基于 Go 语言实现

特点：

• 完全复制：集群中的每个节点都可以使用完整的存档
• 高可用性：Etcd 可用于避免硬件的单点故障或网络问题
• 一致性：每次读取都会返回跨多主机的最新写入
• 简单：包括一个定义良好、面向用户的 API（gRPC）
• 安全：实现了带有可选的客户端证书身份验证的自动化 TLS
• 快速：每秒 10000 次写入的基准速度
• 可靠：使用 Raft 算法实现了存储的合理分布

2.交互

etcd 对外通过 HTTP API 对外提供服务，这种方式方便测试（通过 curl 或者其他工具就能和 etcd 交互），也很容易集成到各种语言中（每个语言封装 HTTP API 实现自己的 client 就行

提示： etcd为服务主文件，etcdctl为命令客户端，只有这两个配置

2.工作原理

3.工作目录

etcd会在默认的工作目录下生成两个子目录：snap和wal。两个目录的作用说明如下：

snap：用于存放快照数据。etcd为了防止WAL文件过多就会创建快照，snap用于存储etcd的快照数据状态

wal：用于存放预写式日志，其最大的作用是记录整个数据变化的全部历程。在etcd中，所有数据的修改在提交之前，都要写入WAL中。使用WAL进行数据的存储使得etcd拥有故障快速恢复和数据回滚两个重要的功能

3.注意

初始化的时候就需要确定

\1. --auto-compaction-retention

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

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

2.--max-request-bytes

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

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

3.--quota-backend-bytes

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

＃启动命令
/usr/bin/etcd --auto-compaction-retention '1' --max-request-bytes '33554432' --quota-backend-bytes '8589934592'

＃启动命令
/usr/bin/etcd --auto-compaction-retention '1' --max-request-bytes '33554432' --quota-backend-bytes '8589934592'

注：删除操作前记得对etcd进行快照的备份，etcd的配额大小可以进行配置，需要到etcd.service文件中添加如下参数： ExecStart=/usr/bin/etcd --quota-backend-bytes ‘8589934592’(根据自己实际需求来改