TiDB Bug List=

【本贴用于记录TIDB中遇到的bug ,方便大家查阅,内容来源于tug的问题整理,除bug 类信息请不要回复,内容补充需考的大家一起维护】

1、bug-11217: 多key GC调用导致GC不工作,大量历史版本残留

2、bug-11903: 计数器错误导致drop/truncate后GC delete range不工作,报gc work is too busy

3、bug-12934: [Critical bug] 切换 PD Leader 或重启 PD 可能导致 SQL 执行持续报错

4、bug-5687: [Critical bug] TiFlash 在开启 Profiling 以后偶发崩溃

5、 bug-37238: [Critical bug] Outer join 的结果可能执行不正确

2赞

bug-11217: 多key GC调用导致GC不工作,大量历史版本残留

影响版本

  • v5.0.0-v5.0.4
  • v5.1.0-v5.1.2
  • v5.2.0-v5.2.2

issue: https://github.com/tikv/tikv/issues/11217
TiKV GcKeys task doesn’t work when called with multiple keys (at least in 5.1 but I think for everything)

现象和确认方法

  • 部分 scan 相关操作执行慢,集群中有比较多的 UPDATE/DELETE 语句执行
  • EXPLAIN ANALYZE 的 scan detail 中显示 key_skipped_count 远远多于 total_process_keys 或者 slow log 中 key_skipped_count 远远多于 total_process_keys

解决方案

  • 设置 gc.enable-compaction-filter: false 以关闭 TiKV 的 compaction filter GC,使用旧的 GC 模式进行多版本 GC
  • 升级到新版本,如上所述选择发行版最新的发布版本
1赞

bug-11903: 计数器错误导致drop/truncate后GC delete range不工作,报gc work is too busy

问题

在 TiKV GC worker CPU 使用率 100% 期间内,执行 drop table 或 truncate table 命令,可能遇到删除表后 TiKV 空间不回收的问题。且 GC worker CPU 下降后,后续执行 drop table 或 truncate table 依然不会回收空间。

问题原因

TiDB 的 drop table 和 truncate table 命令会发送 unsafe destroy range 请求给 TiKV 删除一个范围的数据。

在 TiKV GC worker 繁忙时,GC worker 的 pending task 数量可能达到上限。此时如果继续向其中添加 unsafe destroy range 任务时,会错误地增加任务数量的计数器但最终没有减小。

多次这样的操作后,该计数器的值会永久性地高于 GC worker 繁忙的阈值。之后所有的 unsafe destroy range 请求都会被 TiKV 拒绝,造成 drop/truncate table 后删除数据不成功。

GitHub issue: https://github.com/tikv/tikv/issues/11903
– False GcWorkerTooBusy caused by incorrect scheduled_tasks

排查确认

  1. TiDB 监控的 GC - Delete Range Failure OPM 中有持续的 send 失败,如图:

image.png

  1. TiDB 日志中确认 Delete Range 错误原因是 “gc worker is too busy”
  2. 从原理上再次确认,检查 TiKV 曾经出现过 GC worker 持续 CPU 100% 的状况。

解决方案

Bugfix PR: https://github.com/tikv/tikv/pull/11904

修复版本:5.0.7, 5.1.4, 5.3.1, 5.4.0

临时解决措施

  1. 如果当前 TiKV GC worker CPU 使用率不高,可以重启 TiKV 实例重置错误的计数器,暂时规避问题。
  2. 避免在 TiKV GC worker CPU 使用率高的时候执行 drop table/truncate table 操作。

bug12934: [Critical bug] 切换 PD Leader 或重启 PD 可能导致 SQL 执行持续报错

产品 TiDB
组件 PD TiKV
版本 5.4.2 5.3.2
分类 Troubleshoot
标签 KnowIssue
来源

Issue

在对 PD 进行 Transfer Leader 或重启操作后,集群出现 SQL 执行持续报错的现象。

6.2.0 测试中发现了该问题:https://github.com/tikv/tikv/issues/12934

受到该 bug 影响的版本:v5.3.2, v5.4.2

Diagnostic Steps

  1. TiDB 监控观察到 SQL 执行持续报错,报错为 Region Unavailable / Region Epoch not match 等

  2. TiKV 监控中 TiKV Details - PD - PD heartbeats 中观察到持续快速上涨的 pending

image

Resolution

升级 TiKV 至修复了该 Bug 的版本。

Bug Fix PR: https://github.com/tikv/tikv/pull/13094

预期修复版本:v5.3.3, v5.4.3

bug-5687: [Critical bug] TiFlash 在开启 Profiling 以后偶发崩溃

产品 TiDB
组件 TiFlash
版本 6.1.0
分类 Troubleshoot
标签 KnowIssue
来源

Issue

TiFlash 在运行中偶尔出现某些系统调用(诸如 write())返回非法的 errno,由于程序无法处理非法 errno,所以最终会导致进程崩溃。由于仅在开启 Profiling 期间复现出该问题,因此怀疑与 Profiling 相关。

Github issue: https://github.com/pingcap/tiflash/issues/5687

Diagnostic Steps

  1. 观察 TiFlash 崩溃时的日志和 stack trace,判断它们是否是非法 errno 导致的。
  2. 判断当前是否存在 Profiling 动作(包括 Continuous Profiling,Manual Profiling,调用 /debug/pprof/profile 接口)

Workaround

在 TiDB Dashboard 关闭 Continuous Profiling,并且暂时不要在对 TiFlash 进行 Manual Profiling。

NOTE: 目前只有 v6.1.0 和 v6.2.0 版本默认开启 Continuous Profiling,我们从 v6.1.1 版本开始默认关闭 Continuous Profiling。

1赞

bug-37238: [Critical bug] Outer join 的结果可能执行不正确

产品 TiDB
组件 TiDB
版本 6.1.0
分类 Troubleshoot
标签 KnowIssue
来源

Issue

https://github.com/pingcap/tidb/issues/37238

Root Cause

当 tidb_enable_outer_join_reorder 设置为 true 时,

join reorder 处理过程中对 join 的 ON condition 处理有误

Diagnostic Steps

当存在多个 outer join,各自的 ON condition 中的条件比较简单,只涉及不多于两个表,而且涉及了多个 outer join 的公共外表时,其结果有可能出错。

  • A left join B_1 on F_1 left join B_2 on F_2 left join B_3 on F_3 left join B_i on F_i
  • 所有的连接条件 F_i 都各自只涉及两个表。其中有两个 join 的连接条件 F_i, F_j,F_i 涉及的表是 A 和 B_i,F_j 涉及的表示 A 和 B_j。而且此时有在 F_i 和 F_j 中有一个连接条件只涉及表 A。
  • 这时可能因为 join reorder 的一些处理不当导致结果可能出错

Resolution

修复 pr https://github.com/pingcap/tidb/pull/37245

修复版本 6.1.1 6.2.1

1赞