【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v7.1.1
【复现路径】今天发现这个cluster的tikv节点日志有点多,然后想着通过配置server_configs下的 tikv: log.file.max-days: 5参数来调整日志保留天数,结果修改配置文件后,reload相关节点后,日志并没有减少,发现20号的日志还有。
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
遇到类似问题了么?
差不多,我修改的tikv的,部分节点生效了……
那只能升级版本,或者把配置文件中不合规的配置去掉。
明天再看看,我猜可能是个定时任务删除的
别的集群我记得改了这个参数,然后reload完节点之后,日志就删除了呢~
是的,应该是实时的。估计是遇到相同的bug问题了。检查一下未生效节点的配置文件,是不是有手工直接改节点上的配置文件?
没有手动改的,基本都是通过tiup来调整配置。换成max-backups了,控制下日志文件个数吧……
那为什么有的节点生效了,有的节点未生效?奇怪。
不知道,不生效的节点reload完之后变成了disconnect状态了,然后restart这个节点,就恢复正常了……
直接看看这个节点上的配置文件呢?看看有没有下发成功?
成功了,就是没生效……怪得很
按节点重新reload呢。
执行如下 SQL 看下
show config where type='tikv' and name like '%log.%';
max-backups测试过是可以生效的,你说的这个倒没有去测试过,控制文件个数和文件大小组合的方式来控制整个日志文件的大小了
这里有几个可能的原因和解决方案:
-
配置未生效:修改配置后,需要确保配置被正确地加载。您可以通过
tiup cluster reload
命令来重新加载集群配置,确保新的配置被应用。根据搜索结果,使用tiup cluster reload
命令可以滚动分发配置并重启组件,这有助于确保新的配置被应用。 -
配置文件位置:确保您修改的是正确的配置文件。TiKV 的配置文件通常位于
deploy_dir
目录下的config.toml
文件中。您需要确认修改的是这个文件,并且修改的是server_configs.tikv
下的log.file.max-days
参数。 -
日志清理机制:TiKV 的日志清理机制可能需要一定的时间来处理旧的日志文件。如果日志文件没有立即减少,可能是因为清理机制还没有运行或者还没有到达清理的时间点。
-
日志文件的所有权和权限:有时候,如果日志文件的所有权或权限设置不正确,可能会导致 TiKV 无法删除旧的日志文件。您需要检查日志文件的权限,确保 TiKV 进程有足够的权限来删除这些文件。
-
手动清理日志:如果自动清理机制没有工作,您可以尝试手动删除旧的日志文件。但是,这通常不推荐,因为它可能会干扰 TiKV 的正常日志管理。
-
检查日志文件路径:确认
log.file
参数指定的日志文件路径是否正确。如果路径设置错误,新的日志文件可能会被保存在不同的位置,导致旧的日志文件没有被覆盖或删除。