log.file.max-days参数不生效

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v7.1.1
【复现路径】今天发现这个cluster的tikv节点日志有点多,然后想着通过配置server_configs下的 tikv: log.file.max-days: 5参数来调整日志保留天数,结果修改配置文件后,reload相关节点后,日志并没有减少,发现20号的日志还有。
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
image

遇到类似问题了么?

1 个赞

差不多,我修改的tikv的,部分节点生效了……

:yum:那只能升级版本,或者把配置文件中不合规的配置去掉。

明天再看看,我猜可能是个定时任务删除的

别的集群我记得改了这个参数,然后reload完节点之后,日志就删除了呢~

1 个赞

是的,应该是实时的。估计是遇到相同的bug问题了。检查一下未生效节点的配置文件,是不是有手工直接改节点上的配置文件?

没有手动改的,基本都是通过tiup来调整配置。换成max-backups了,控制下日志文件个数吧…… :sweat_smile:

:thinking:那为什么有的节点生效了,有的节点未生效?奇怪。

不知道,不生效的节点reload完之后变成了disconnect状态了,然后restart这个节点,就恢复正常了…… :joy:

1 个赞

直接看看这个节点上的配置文件呢?看看有没有下发成功?

成功了,就是没生效……怪得很

:yum:按节点重新reload呢。

1 个赞

执行如下 SQL 看下

show config where type='tikv' and name like '%log.%';
1 个赞

max-backups测试过是可以生效的,你说的这个倒没有去测试过,控制文件个数和文件大小组合的方式来控制整个日志文件的大小了

这里有几个可能的原因和解决方案:

  1. 配置未生效:修改配置后,需要确保配置被正确地加载。您可以通过 tiup cluster reload 命令来重新加载集群配置,确保新的配置被应用。根据搜索结果,使用 tiup cluster reload 命令可以滚动分发配置并重启组件,这有助于确保新的配置被应用。

  2. 配置文件位置:确保您修改的是正确的配置文件。TiKV 的配置文件通常位于 deploy_dir 目录下的 config.toml 文件中。您需要确认修改的是这个文件,并且修改的是 server_configs.tikv 下的 log.file.max-days 参数。

  3. 日志清理机制:TiKV 的日志清理机制可能需要一定的时间来处理旧的日志文件。如果日志文件没有立即减少,可能是因为清理机制还没有运行或者还没有到达清理的时间点。

  4. 日志文件的所有权和权限:有时候,如果日志文件的所有权或权限设置不正确,可能会导致 TiKV 无法删除旧的日志文件。您需要检查日志文件的权限,确保 TiKV 进程有足够的权限来删除这些文件。

  5. 手动清理日志:如果自动清理机制没有工作,您可以尝试手动删除旧的日志文件。但是,这通常不推荐,因为它可能会干扰 TiKV 的正常日志管理。

  6. 检查日志文件路径:确认 log.file 参数指定的日志文件路径是否正确。如果路径设置错误,新的日志文件可能会被保存在不同的位置,导致旧的日志文件没有被覆盖或删除。