kubernetes 的 tiflash 频繁coredump 导致磁盘爆满

[foxchan (银狐)]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：v4.0.5
• 【部署环境】: kubernetes1.16& centos 7
• 【问题描述】：
  tiflash 频繁coredump ，导致pod 所在机器磁盘空间迅速充满。
  tiflash 默认镜像ulimit -c 没有限制，导致。
  
  
  
  
  
  
  
  core 文件太大无法上传

能不能官方在作镜像的时候限制下ulimit 配置，kubernetes目前无法限制ulimit

[leiysky]

你好，请问方便提供下 TiFlash 和 TiDB 的 log 文件吗？ulimit 的问题我们后续会关注。

[foxchan (银狐)]

tidb 日志
链接: https://pan.baidu.com/s/1h3JZgxkM-83taCcYfvrESA 提取码: tm5v

tiflash 因为 重做，日志都清理了

发现4.0.5发布了，就想着升级下集群组件，现在重做tiflash 4.0.2， 偶尔仍然有coredump，但是比4.0.5 少很多了

[leiysky]

log 没有发现什么异常的情况，猜测 coredump 可能是 OOM 引起的，可以使用

dmesg | egrep -i 'killed process'

之类的方式查看 OOM killer 的日志。

如果不是 OOM 引起的话，可以把 coredump 的 backtrace 提供一下(TiFlash 的二进制文件名字就是 tiflash)，方便进一步的排查。

[foxchan (银狐)]

内存还有很多，没有oom
backtrace是这样吗

coredump 放这里了
链接: 百度网盘-链接不存在 提取码: 6uzy

[leiysky]

这个 coredump 需要结合 TiFlash 的二进制文件来查看，指令是

$ gdb path/to/tiflash core.xxxxx

我刚刚尝试用 4.0.2 和 4.0.5 的 TiFlash 来解析这个 coredump，但是都不匹配，在你们的环境里用的具体是哪个版本呢？

[solotzg-PingCAP]

现在已经查明，是4.0.5的cluster manager在统计数据同步进度的时候出了问题，没有妥善处理 status address 返回 404 not found 的情况，后续会修正

客户环境在手动配置 status address 后恢复正常，详细步骤为：

1. 先通过 tidb 查询哪些表正在同步数据 SELECT * FROM information_schema.tiflash_replica where AVAILABLE!=1;

2. 如果步骤 1 返回空，进入步骤 3，否则先将这些表的 tiflash replica 设为 0 来暂时停止 tiflash 内部会产生 segment fault 的行为

3. 如果是 tiup 部署，走正常的滚动升级流程即可，否则需查看集群的 store 信息，若 tiflash 节点的 status_address 为默认的 127.0.0.1:20180，可手动修改配置文件目录下有个名为 proxy 或者 tiflash_tikv 之类的 toml 文件，在 server 栏目下添加图中类似的 status-addr 和 advertise-status-addr 项，如果是 docker 部署需做好相关端口的映射，例如

[server]
engine-addr = "tiflash0:3930"
status-addr = "0.0.0.0:20181"
advertise-status-addr = "tiflash0:20181"

4. 等到所有 tiflash 节点的升级完毕，且节点的 status_address 信息都被修正后，再正常流程为表设置 tiflash replica