br log 支持定时清理 S3 上的日志

[dba-kit (张天师)]

需求反馈
当前br log在 PITR 日志文件管理方面，还有些功能不太好用，具体有两点：

1. br log task 其实已经将 S3 配置信息存到 etcd 中了，在执行 br log truncate/meta 时候是否可以根据 task-name 来获取对应的 S3 地址，而不是再手动传输一次 S3 配置。
2. br log truncate 是否能增加一个类似 MySQL 的 expire_logs_days 参数的选项，由 task 自动清理过期的日志文件，而不是由用户在外层通过封装 crond 来实现定时清理，再叠加现在执行 br log truncate 时候还必须传入 AK/SK， 也增加了密码泄露的风险。

[caiyfc]

支持支持！

[WalterWj (王军 - PingCAP)]

当前：

1. OP 部署弄个 cronjob 跑 br log truncate
2. tidb cloud 和 tidb-operator (https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/backup-restore-cr#backupschedule-cr-字段介绍) 都有对日志定期清理的支持。

和研发沟通：br 内核暂时没内置这种调度和生命周期管理的能力。 可以开一个 frm， 但排期不会太早。
这个需求其实有在规划，其实不是个小的特性，内核目前还不具备定时调度的基础能力， 尽管 tidb 有 timer 的支持， 用在了 ttl 上。 总之， 需要好好规划这个。

ISSUE 我这边建了一个：Issues · pingcap/br · GitHub
内部也提了产品需求，等 PM 分析了。

[WalterWj (王军 - PingCAP)]

br 这个 repo 已经废弃了，都转战到 tidb repo 了。 新 issue br: br: enable log backup retention support · Issue #54842 · pingcap/tidb · GitHub

[WalterWj (王军 - PingCAP)]

@dba-kit

br log task 其实已经将 S3 配置信息存到 etcd 中了，在执行 br log truncate/meta 时候是否可以根据 task-name 来获取对应的 S3 地址，而不是再手动传输一次 S3 配置。

关于这个需求，现在设计上希望 truncate 可以独立于上游集群做，所以最初没有做直接从上游集群拉 storage 信息。为了解耦我理解很难来做这个。

我个人觉得这个存 etcd 长期来看也不是那么合理🤔