TiDB集群昨天变得很慢,重启后,今天研发同事发现少了一批表

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

  • 【TiDB 版本】:TiDB4.0 TiUP部署
  • 【问题描述】:昨天的问题请参照昨天的贴子,这个现象能解释么?或者查找什么日志能查找到被删除的痕迹。
    被删除的表都是以kpi_开的头的表

    TiDB集群突然变得好慢,有什么办法能定位到问题呢?

    若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

这个可以看 GC 的相关监控可以确认是否有大量的 delete range 操作 以及 TiDB Server 的 SUmmary 面板中的 Statement OPS 监控可以到是否有 DDL语句操作。

可以参考一下 TiDB log 是有记录的。

关键词 ”CRUCIAL OPERATION“

通过GC的delete range可以发现没有这个处理




按照CRUCIAL OPERATION这个关键词搜索了一下,这些都程序操作的,没有被删除的以kpi_开头的表

是不是日志切割了 ?

现在查的是这个日志,昨天的9点多的都在这里面

image

如果有就是类似这样的 log ,或者看看有没有 rename table 操作。

拿记录本和直接在服务器上面使用grep都过滤不到以kpi_开头表

麻烦发一下 DDL history 记录可以确认是否有删除的操作,操作方法通过 TiDB API 查看 DDL history 记录从定向到 log 中。

# Get all TiDB DDL job history information.

curl http://{TiDBIP}:10080/ddl/history

数据导出来了,有712M,使用工具查找了一下,没有匹配的以kpi_开关的表的删除。image

你好,

请提供下楼上的需要的排查信息。

curl http://{TiDBIP}:10080/ddl/history