5.2 生命周期管理：让数据自己流动

5.2 生命周期管理：让数据自己流动

本节摘要：生命周期管理（ILM）把"数据老了之后怎么办"变成写一次就永久生效的规则：到期删除、非当前版本清理、删除标记清理、以及向远程存储层（如公有云冷存储）的到期转移。本节按"规则的四种动作 + 一套真实的分层配置"展开。

为什么删除脚本不是答案

管理数据寿命的第一反应通常是写个定时任务：每晚跑一遍，删掉过期的。这个方案在对象量小的时候能活，规模一大就露怯：遍历亿级对象做时间判断，跑一次几小时，误删了没法查证，脚本逻辑散落在 crontab 里没人敢动。生命周期规则把这套逻辑下沉到存储层：规则挂在桶上，扫描与执行由 MinIO 的后台任务完成，没有脚本要维护，没有遍历要担心，行为可以随时审计。数据按规则自动归置，这正是"让数据自己流动"的含义。

四种规则动作

生命周期规则的动作词汇表有四个，组合起来覆盖绝大多数场景：

动作一：到期删除（expiry）。 对象写入后满指定天数，自动删除。适合会话文件、临时导出、拼接中间产物这类"生下来就知道死期"的数据。

动作二：非当前版本清理（noncurrent expiry）。 只作用于版本控制桶里的非当前版本：历史版本满 N 天后清理。这是 5.1 结尾那笔容量账的标准解法——当前版本受保护，历史版本有寿数。

动作三：删除标记清理（delete marker expiry）。 当一个删除标记之下没有任何数据版本时，把标记本身清掉。没有这条规则，删除标记会永久堆积，拖慢列举。

动作四：到期转移（transition）。 对象满 N 天后移动到远程存储层——典型去处是公有云的低频或归档存储。本地只留目录，桶的命名空间不变，应用无感。这是分层存储经济学的入口：热数据在本地 NVMe 上飞奔，冷数据去云端按低价躺着。

规则的写法以 mc 为例：

# 规则一：export 临时桶,对象 7 天后删除
mc ilm rule add --expire-days 7 fleet/tmp-export

# 规则二：配置桶,非当前版本 30 天清理,删除标记自动清
mc ilm rule add --noncurrent-expire-days 30 --expire-delete-marker fleet/app-config

# 规则四：先配置远程层,再挂转移规则（对象 90 天后转移到云端归档层）
mc admin tier add remote minioalias cloud-archive <厂商与凭据参数>
mc ilm rule add --transition-days 90 --transition-tier cloud-archive fleet/media-archive

# 查看与验证：规则的清单与模拟
mc ilm rule ls fleet/app-config
​

⚠️ 常见坑：转移规则的远程层配置一旦写坏（凭据失效、桶名错误），转移任务会持续失败重试，而告警若只盯着本地水位就毫无察觉。挂上转移规则后，第一周要主动核对远程层里确实出现了对象——规则配置的验收在远端，不在本地。

图 5-2 一个媒体归档桶的分层流转

规则设计的三个实践口径

口径一：按桶分治，不搞全集群一条规则。 不同桶的数据寿命天然不同：临时桶、配置桶、归档桶的规则各写各的。试图用一条万能规则覆盖所有桶，最后一定变成"对某些桶太狠、对另一些桶太松"。

口径二：转移决策算总账。 转移省下的是本地容量，付出的是取回成本与访问延迟。媒体素材若三个月内还可能被重新剪辑，转到取回慢且贵的归档层就是省小钱误大事。转移天数定在"访问频率跌破阈值"之后，用监控数据说话，而不是拍脑袋。

口径三：删除规则的试运行。 新挂的到期删除规则，先用一个测试桶观察一周：到期对象是否如时消失、有没有误伤。删除是不可逆的（对没有版本控制的桶），规则的第一次生效值得全程盯着。

FAQ：规则执行的时间与边界

到期后多久真正删除？

后台扫描周期性执行规则，删除发生在扫描覆盖到该对象时，通常在到期日之后的一到两个扫描周期内。不要把生命周期当作精确到秒的定时器，它是按天粒度的归置机制。

转移出去的对象还能改吗？

转移层是只读的：本地只剩占位信息，任何修改请求要先取回或重新写入。设计转移策略时把"转移即冻结"当作前提。

规则和对象锁定冲突吗？

冲突时锁定优先：处于保留期内的版本不会被执行删除或覆盖，即使生命周期规则说它到期了。合规约束压倒运营规则，这个优先级是刻意的。

本节要点回顾

• 四种动作：到期删除、非当前版本清理、删除标记清理、到期转移，覆盖数据寿命的全部常见诉求。
• 版本桶的标配组合：非当前版本清理加删除标记清理，保护与容量兼得。
• 转移规则验收在远端：配置挂上只是开始，远程层出现对象才算生效。
• 按桶分治、试运行、算总账：规则设计的三条工程口径，比动作词汇表更重要。

数据会自己流动了，但如果有人连"流动"都不被允许呢？下一节讲对象锁定——让删除这个动作本身失效。

规则调试的两个疑问

规则可以只作用于某个前缀吗？

可以。规则支持按前缀过滤——"logs 前缀七天删、archive 前缀三百天转冷"这样的差异化诉求，在同一个桶里用多条规则各管一段即可。但前缀规则一多，可读性迅速劣化，建议把规则数量视为坏味道：超过三五条还理不顺，就该拆桶了。规则是桶级的配置资产，拆桶同样是配置资产的重组。

挂了规则之后，怎么确认它在干活？

三个观察点：规则清单命令确认规则在册；对一个已知到期的对象，等待一至两个扫描周期后确认其消失（或转移）；长期看，容量曲线的斜率应与规则预期一致——清理类规则让水位出现"锯齿"，转移类规则让本地增速放缓。三者结合，规则的真实性就有了证据链。凡是自动化的东西，都要设计一条"确认它真的在跑"的观察路径——这条经验不限于生命周期管理。

规则与备份策略的接力

生命周期还有一个容易被忽略的搭档角色：给备份体系做"自动减负"。8.3 会讲到备份的三条腿，其中定期镜像那条腿最怕备份集无限膨胀——每一轮全量镜像都在往备份集群堆新字节。生命周期规则在备份目标桶上挂一条"非当前版本三十天清理"，备份集就自动收敛到"最近三十天可回溯"的窗口，备份容量从无底洞变成可预算的常数。同理，5.1 案例里 CI 每天覆盖配置对象产生的历史版本、开发测试桶里日积月累的临时产物，都可以由规则代劳清理。**规则的价值不只在"删除"，更在把"数据该活多久"这个每次都要人操心的问题，变成一次性写死的政策。**当你发现自己第三次因为"某个桶满了要清理"登录集群时，正确的反应不是再删一次，而是挂一条规则让这个问题永远消失。