【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5
【复现路径】默认安装的集群
【遇到的问题:问题现象及影响】一台机器tidb组件日志过大
【资源配置】
监控界面第一台机器磁盘占用过大,查出来是tidb的日志问题
以下是问题服务器的日志
![问题服务器](https://asktug.com/uploads/default/original/4X/1/3/c/13c997b997e65f46624f90703d2825250ce8a9f2.png)
![异常日志](https://asktug.com/uploads/default/original/4X/b/e/0/be0f21f2eb48667286e56cd4778d6aaa129db5b1.png)
以下是正常服务器的日志
![正常服务器](https://asktug.com/uploads/default/original/4X/b/9/a/b9ad0495bbc2ada3324fd1d90c4b16e8887d5e48.png)
![正常日志](https://asktug.com/uploads/default/original/4X/7/b/f/7bf382a3dc48c7461e87e7b9e21283d33d851ea9.png)
检查show config where name like ‘%log.%’
两台机器log.file.max-days参数均为0
为啥只有第一台机器产生了日志堆积(大概产生了70G的日志)
【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5
【复现路径】默认安装的集群
【遇到的问题:问题现象及影响】一台机器tidb组件日志过大
【资源配置】
看一下日志是啥,可能中间有段时间网络之类的出问题了,导致打了很多日志,不需要的话可以手动删除日志
里面存了一些sql操作信息,应该不是网络问题,日志跨度从今年3月至今
你们 TiDB 的连接是直连的还是有LVS分配之类的
直连的
那可能是负载均衡没做好吧,都跑到一台 TiDB 上了
是哦!感谢
建议上面加个负载均衡,然后根据 CPU 能力进行分配下,除此之外那些多余的历史文件手动删除吧
感觉仅仅是一个tidb节点在工作,其他的节点一点日志没有,肯定不对的。
看看是不是负载均衡的问题。
lz用的是什么负载均衡,感觉负载均衡失效了。
做个负载均衡
建议用硬件的负载均衡,如F5。