3.2 位衰减防护与后台自愈
3.2 位衰减防护与后台自愈
本节摘要：位衰减是磁盘不报错、S.M.A.R.T. 无异常、数据却悄悄变了的静默损坏。MinIO 用"分片级哈希指纹 + 读取即校验 + 后台巡扫自愈"三层防线应对它。本节讲清三层各自怎么工作，并给出一条从发现到修复的完整操作实录。
盘没坏，数据为什么还是错了？
存储行业有个不受欢迎的统计规律：一块在服役中的盘，可能在你毫无察觉的情况下返回错误的数据。原因从宇宙射线引发的比特翻转，到固件缺陷导致的写偏移，再到静悄悄长出来的坏扇区（盘把它重映射进备用区时如果没读出来源数据，错误就被固化了）。这类损坏的共同点是沉默——文件系统能读、字节数对得上、S.M.A.R.T. 全绿，直到某天业务发现三年前的备份包解不开了。学界给它起了个名字：bitrot,位衰减。对"数据放进去就是要放十年"的对象存储而言，位衰减是比盘坏更阴险的敌人，因为盘坏至少会响警报。
第一层防线：每个分片都带指纹
MinIO 在写入时给每个分片算一个高强度哈希指纹（HighwayHash 算法，选用它正是因为针对恶意构造冲突的防御设计），指纹与分片一起落盘。读取任何一个分片，第一件事是重算指纹、与落盘指纹比对：一致才放行，不一致立即判定该分片损坏——当场从其余健康分片重构出正确数据返回给应用，应用全程无感。
这个设计的精妙在粒度。如果校验发生在对象级，一个对象十几个分片里藏着一个坏分片，你得把整个对象重写；分片级校验把修复范围锁定到一块盘上的一个分片文件，修复代价是毫秒到秒级。指纹算法本身经过向量化优化，校验开销在整体读写延迟里占比很小——这是"每个读都校验"在经济上可行的前提。
第二层防线：后台巡扫
读取即校验有个盲区：三年没人读的归档对象，坏三年都无人知晓。所以 MinIO 内置了后台扫描（scrub）,像仓库巡夜一样轮询所有纠删集，主动重算分片指纹。扫描以低优先级运行，会为业务读写让路；发现坏分片的处理与读取路径一致——立即用健康分片重构、写回修复。扫描进度与发现量可以通过管理接口观察，是 8.2 监控面板上的常驻图表。
第三层防线：heal 与它的正确用法
heal 是显式的修复指令，也是运维手里最常用的自愈工具。它的语义值得细读：对指定范围（集群、池、桶或单对象）检查所有分片状态，把缺失或损坏的分片从健康分片重构出来，写回当前可写的盘位。
# 先做演习：dry-run 只报告将要修复什么，不动真格 mc admin heal --dry-run fleet/courseware # 对单个桶做递归修复 mc admin heal -r fleet/courseware # 输出要点解读： # Scanned objects / scanned versions —— 巡检范围 # healed objects —— 实际修复的对象数 # non-healed —— 修不动的（通常健康分片已不足，需人工介入）
三条使用纪律来自真实的翻车记录。纪律一：先演习后动刀。dry-run 的输出会告诉你修复波及多少对象，心里有数再执行。纪律二：换盘后必 heal。2.3 的坏盘案例里，新盘插入只是被纳为可写盘位，迁出的分片要靠 heal 铺回来——不 heal,集群就带着"带伤的冗余"运行，下次故障可能击穿容错线。纪律三：避开业务高峰。heal 是 IO 密集操作，海量小对象桶的重构会与业务读写抢带宽，定时任务安排在业务低谷，并用限速参数控制节奏。
分片在三层防线中的流转可以用一张状态图概括：
图里那条通往"丢失风险"的边是全章最该记住的：自愈不是无限的，当纠删集里健康分片数低于数据分片数 k,数学不再兜底。这就是 3.1 强调健康水位、8.2 强调告警阈值的原因——防线要靠人守在数学失效之前。
案例：一次归档桶的静默损坏处理
背景：某法务归档桶，对象写入后按合规要求保存多年，几乎零读取。例行月度巡检时，后台扫描报告该桶一个纠删集内有分片指纹不符。
操作：工程师按标准流程处置。第一步，确认水位：该集 12 个分片全部可读，损坏分片已在上次扫描后被自动重构修复，冗余完整。第二步，溯源：查该盘的固件版本，发现属于某批次已知的静默损坏问题盘。第三步，决断：申请将该批次 4 块盘整体轮换，而非等它们逐个发作。第四步，收尾：每换一盘执行定向 heal,四块盘分两周轮完。
结果：全程零告警、零业务影响，事后归档抽检全量通过指纹校验。
解读：这个案例里真正起作用的不是 heal 命令，而是"扫描发现 + 水位确认 + 批次盘轮换"的决策链。位衰减的可怕在于单点，破局靠的是把散点事件归因到批次——同一批盘的固件缺陷是相关的，一颗雷响了要排整片雷区。
变式：若发现时健康分片已不足 k（例如该集同时有两块盘离线且损坏分片恰好分布在其中），heal 无法完成，此时唯一的生路是从复制目标（5.4 的站点复制）或更早的备份拉回数据——这是"纠删码不能替代异地容灾"的现场注脚。
本节要点回顾
- 位衰减是静默敌人：盘会返回错误数据而不报错，防护必须内建于存储层而非依赖外挂校验。
- 三层防线各管一段：分片指纹管"读到的必对"，后台巡扫管"没人读的也查"，heal 管"坏了的修回来"。
- heal 三纪律：先演习、换盘后必补、避开高峰——命令本身简单，纪律才是稀缺品。
- 自愈有边界：健康分片跌破 k 就没有数学解，异地复制与备份是不可替代的最后一道。
数据不丢搞定了，还有个更挑剔的承诺：写完马上读，读到的必须就是刚写的。下一节讲这条承诺如何兑现。
巡扫与修复的三个运维疑问
后台扫描能不能关掉省 IO？
技术上可调慢、不建议关闭。关掉扫描等于放弃"没人读的数据也能被检查"的能力，归档桶的静默损坏将完全失控。正确做法是给扫描安排节奏：低配硬件用慢速档，并与 7.2 的调参联动，把扫描 IO 的优先级压到业务之下。
扫描周期是多久？能查进度吗？
扫描以纠删集为单位轮转，周期取决于集群规模与档位，日常运维不需要精确掌握——需要掌握的是进度与产出的可见性：扫描状态与发现量都有管理接口可查，接进 8.2 的监控面板后，"今天扫了多少、发现几处分片异常"是一张常驻图表。
heal 跑到一半中断了怎么办？
heal 是可安全重入的操作：中断后重新执行，它会从上次的状态继续比对与修复，不会造成二次损坏。需要注意的只是重试的时机——如果中断的原因是业务高峰，换个窗口再来；如果是坏盘加剧，先处理盘再 heal。恢复类操作永远遵循"先看水位，再动工具"的顺序。