【 使用环境 】生产环境
【 OB or 其他组件 】OCP
【 使用版本 】4.3.3-20241219140415
【问题描述】想请教一下这个日志备份能否清理或者轮转的,已经占用了3个T了
【复现路径】问题出现前后相关操作
【附件及日志】
我的ocp版本好像没有这个
ocp版本: 4.3.3-20241219140415
ob版本: 4.3.4.1
应该不会吧,这是基础功能,3.x版本的OCP就有了。可以截个图看看
这个是以前离职同事维护的一个机器,以前触发过物理备份,我看没有备份策略了,所以我看不到这个页面,这个日志备份是不是也可以停掉然后把目录清理了
看sg租户有没有备份策略
【租户管理】–>选择sg租户–>【备份策略】
那要登录租户查下备份删除策略视图了,可以查DBA_OB_BACKUP_DELETE_POLICY视图
在sys系统租户查询都是空的
SELECT * FROM DBA_OB_BACKUP_DELETE_POLICY
那就没配置清理策略,可以按照官方文档配置
MySQL租户应该是这个语法
ALTER SYSTEM ADD DELETE BACKUP POLICY 'default' RECOVERY_WINDOW '7d';
自动清理任务由后台系统每小时定时触发,因此清理策略设置完成后,可能需要等待一段时间(不超过一小时)才能查询到相对应的清理任务。
好的,我试试
查了很多信息都是指向必须有数据备份才会触发日志归档的清理
由于现在这个服务器已经没有做数据备份了,计划关闭日志归档模式,然后去手动清理
就是不知道手动清理会不会导致某些未知问题
home/oceanbase/sgoceanbase/store/arckive
-- 关闭日志归档模式
ALTER SYSTEM NOARCHIVELOG TENANT = "sg";
OceanBase 的过期日志清理是挂在「可恢复窗口」上的,窗口的锚点是数据备份集。 没有可用的数据备份,内核就不知道哪些 piece 过期,清理策略基本不会动 clog。先停日志归档,再手工删文件是合理路径前提是:这些归档以后不再用于恢复、也没有备库在读这条 dest。




