etcd 延迟治理：压缩、碎片整理与磁盘检查

etcd 是控制面的写入路径，磁盘 fsync 延迟会直接放大 API Server 和控制器延迟。排查前先确保快照可用，不要把维护操作当作试错手段。

检查集群状态

ETCDCTL_API=3 etcdctl endpoint status --cluster -w table
ETCDCTL_API=3 etcdctl endpoint health --cluster
ETCDCTL_API=3 etcdctl alarm list

对比各成员的 DB 大小、raft index 和 leader 状态。成员落后或频繁选主时，优先检查网络和磁盘。

区分逻辑大小与物理大小

历史版本经过 compaction 后，数据库文件不会自动缩小。碎片率高时可以逐个成员执行 defrag：

etcdctl compact <REVISION>
etcdctl defrag --endpoints=https://member-1:2379

每次只处理一个成员，并在下一成员前确认健康恢复。大型数据库整理会阻塞该成员，必须安排维护窗口。

监控关键指标

关注 WAL fsync、backend commit、leader changes 和 proposal failures。持续高延迟通常需要更快的独立 SSD，而不是只调大配额。

安全清单

• 验证最新快照可以恢复
• 确认三节点集群至少两节点健康
• compaction 与 defrag 分步执行
• 维护后检查 DB 大小、延迟和告警状态