慢查询报错err: parsing time

  • 【TiDB 版本】:5.7.25-TiDB-v2.1.8
  • 【问题描述】:使用tidb查询slow sql,比如执行select * from INFORMATION_SCHEMA.SLOW_QUERY where Time like ‘2019-12-10 14:10:%’ order by Process_time desc limit 10;

报错内容为 ERROR 1105 (HY000): string "2019-12-07-18:54:50.512400153" doesn't has a prefix that matches format "2006-01-02-15:04:05.999999999 -0700", err: parsing time "2019-12-07-18:54:50.512400153" as "2006-01-02-15:04:05.999999999 -0700": cannot parse "" as "-0700" 昨天执行还可以,除中间正常执行sql外无任何其他操作

问题确认

  1. TiDB Server 对应的 slow query log 是否完整,没有进行日志切割操作?
  2. 有没有进行过 TiDB Server 重启或者 run_tidb.sh 里面的 slow query log 参数设置 ?
  3. 登录 TiDB Server 对应指定的 slow query 确认是否存在 “2019-12-07-18:54:50.512400153” 和 “2006-01-02-15:04:05.999999999 -0700” 数据是否存在 ?
  4. 尝试一下 select * from INFORMATION_SCHEMA. SLOW_QUERY ,没有反馈 ?
  5. 尝试一下 show create table INFORMATION_SCHEMA. SLOW_QUERY ?

1.slow query log应该是默认的,达到300M切割

2.没有重启,run_tidb.sh 里面的 slow query log还是之前的配置,指定保存为tidb_slow_query.log文件

3.因为存在分割日志,在tidb_slow_query*.log里搜索这两个时间对应内容都无记录

4.之前发的截图里有 select * from INFORMATION_SCHEMA. SLOW_QUERY limit 1;的结果,也是一样的报错

5.

麻烦再确认一下其他的 tidb-server 的执行一下 information_schema.slow_query 的反馈正常么 ?

我之前的表述有些问题,执行sql与查log在不同tidb server导致在日志中没grep到,现在的情况是三台tidb server,两台有这个问题,报错的时间点也不一样,其中2019年时间对应的log是有记录的,查询报错如下

在slow log里grep对应时间点内容如下

辛苦按照上述同事的描述,提供下日志详情。感谢。

定位问题了,是触发了旧版本的一个 bug (SQL 里面带有 # 时导致解析慢日志失败) , 升级到 2.1.9 及以后版本即可。

非常感谢

:+1::+1: