【详述】问题详细描述
【背景】做过哪些操作?
【业务影响】
【是否存算分离】
【StarRocks版本】2.3.16
fe参数catalog_trash_expire_second的取值范围是多少?通过ADMIN SET FRONTEND CONFIG (“catalog_trash_expire_second” = “60”);后,60秒之后drop table还是能通过recover table来恢复
另外也提个建议,这些参数解释增加一个取值范围
【详述】问题详细描述
【背景】做过哪些操作?
【业务影响】
【是否存算分离】
【StarRocks版本】2.3.16
fe参数catalog_trash_expire_second的取值范围是多少?通过ADMIN SET FRONTEND CONFIG (“catalog_trash_expire_second” = “60”);后,60秒之后drop table还是能通过recover table来恢复
另外也提个建议,这些参数解释增加一个取值范围
catalog_trash_expire_second 之前默认是3天 后修改成86400一天 跟回收进trash目录保持一致了 时间范围这个我们改进一下 当前我理解没有上限 然后设置成60s后 recover 恢复是因为 当前的策略机制是 drop数据后 会对对应的tablet元数据打一个标签还保留在fe元数据当中 满足了 catalog_trash_expire_second条件后 会进入到trash目录中(由这个参数控制trash_file_expire_time_sec 2.3默认应该还是3天) 所以实际数据还没有删除 还是可以恢复的
drop table之后的数据会移动到be节点的trash目录吗?我这边将catalog_trash_expire_second修改为900之后,drop table后,在be节点并没有trash目录生成