维护

PodDisruptionBudget 限制一组选中 Pod 通过驱逐产生的中断。它可以协助维护期间保留服务容量或法定多数，但不能保证两者必然存在。保护取决于调用者使用 Eviction API、选择器选中正确成员，以及 Ready 条件真正反映应用所需能力。只建立一份对象而不核对这些前提，并不能让维护自动安全。 允许中断多少，应来自应用的失败模型。三成员多数派系统通常需要两个正常成员，但 Pod 就绪本身不证明成员身份、数据同步或成员之间的连通性。PDB 是应用健康检查与维护流程的补充，不会理解数据库协议，也不会自动纠正已经失去同步却仍报告 Ready 的副本。 PDB 约束的是特定驱逐路径。把额度视为安全维护余量前，先核对成员选择、就绪状态、策略与应用健康。 保护边界在驱逐接口 节点崩溃、网络分区和节点压力驱逐，都不会被 PDB 阻止。但已经不可用的成员仍可能减少后续维护可使用的额度。直接删除 Pod 或整个工作负载会绕过预算，工作负载控制器正常滚动更新时的删除也不受它限制。因此“主动中断”不自动等于“必然经过预算保护”，必须看实际调用路径。 ...

在多版本存储里，删除只是记录变化、而不立刻释放空间。回收这些空位需要维护工作，一旦被跳过，代价就会悄悄累积。 删除不等于已经回收 UPDATE 或 DELETE 会留下旧行版本，直到相关快照都不再需要它们。长事务可以在其他会话持续修改数据时推迟这个时刻，但长事务本身不会凭空让一张没有写入的表膨胀。提交删除、旧版本不再可见、空间得到回收，是不同边界。不能只看删除语句成功，就认定这些页面已经可以重新分配。 普通 VACUUM 通常只是让表文件内部的空间可供新行复用，不会缩小文件。末尾完全空闲的页面有时能够截断；一般压缩则需要 VACUUM FULL 一类重写操作，付出额外空间和更强锁的代价。清理成功但文件大小不变，并不意味着失败。要把活数据、内部可复用空间以及真正归还操作系统的空间分别观察，才不会对正常状态反复执行昂贵重写。 清理与统计是不同任务 autovacuum 由启动进程和多个工作进程组成，并非一名常驻 worker 按固定时刻清完所有表。它根据活动估计和年龄相关规则决定是否执行 VACUUM 或 ANALYZE。ANALYZE 独立收集规划器分布统计，普通 VACUUM 不能替代它。插入驱动的工作与防回卷工作也说明，死元组数量并不是维护的唯一触发条件，不能因为暂时没有大量删除就忽略事务年龄。 基于代价的延迟，会在估计 I/O 工作累计到一定程度后暂停一段时间。代价上限不是“一次调用最多删掉多少行，达到后就退出”。阈值影响资格，worker 是否有空影响调度，存储能力和限流则影响推进速度。排查需要先判断卡在哪个阶段，不能把各种迟缓都归结为某个比例系数太大，也不能把模拟程序里的清理额度当成真实数据库参数。 坏掉的样子 第一类问题是产生旧版本的速度超过回收速度。连续几个观察窗口中，死元组估计与关系体积不断上涨。应结合已经完成的运行、取消情况、worker 可用性、I/O 与写入速率检查。资源确实成为瓶颈时，额外硬件可能有帮助；但重启数据库本身不会让仍需保留的版本变得可回收。在相同 I/O 上限下，降低阈值或增加 worker 数量，也不保证最终吞吐更高。 第二类问题是清理在跑，却因为旧快照或保留的 xmin 而无法回收特定版本。干预之前要检查事务及复制状态。事务开始得很早只是线索，不能证明它持有这次受影响的可见性边界。结束应用事务或删除复制槽可能中断工作，甚至让消费者需要重建，因此应先找到负责人、确认保留目的与恢复要求，而不是为了让监控数字下降就直接清除对象。 第三类问题是仅凭一个 n_dead_tup 值或一条慢计划断定膨胀。统计数量是估计，页面布局、可见性、选择率和统计过时都可能改变读取成本。应比较趋势、vacuum 报告和真实执行计划。文件较大但内部空间可复用，可能是健康稳态；死元组较少，也不排除版本保留或冻结问题。不能让单一计数替代完整因果判断。 ...