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 的结果可能执行不正确

6、 tiflash 6.2 无大查询时 内存突增导致oom

7、 6.x版本设置新的tiflash副本后,progress同步进度不更新。

8、6.4版本BR在分区表恢复后使用有问题的partitionID。

9、 v6.3.0-v6.5.0 使用 Multi-schema change 添加唯一索引导致数据索引不一致。

4 个赞

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 操作。
1 个赞

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 个赞

问题
升级到tiflash6.2 后非大查询、压力不大情况下出现oom

影响版本
v6.2 及以后

问题原因:
tiflash 从 6.2 开始引入 PageStorage v3 作为底层存储,可以显著减少写放大和提高写入性能,同时避免后台 gc 的高 cpu 使用。不过也引入了一个 bug,即 PageStorage 在 gc 的,page 的 删除标记 不会被真正回收,导致 wal 文件越滚越大,导致 GC 占用的内存也越来越大。
相关issue:
https://github.com/pingcap/tiflash/issues/6159
https://github.com/pingcap/tiflash/issues/6163

检查确认方式:
1、 无大查询 情况下 tfilash 出现内存突增 导致oom
2、<tiflash_data_dir>/data/page/log/wal/ 目录下,log_xxxx_1 文件持续变大

临时解决措施
使用 ALTER TABLE xxx COMPACT TIFLASH REPLICA 手工进行碎片整理,减少内存占用

修复版本
预计6.4版本修复

可参考:
https://asktug.com/t/topic/994062/41

1 个赞

问题
6.x版本设置新的tiflash副本后,progress同步进度不更新。

影响版本
6.0 - 6.2

问题原因:
region_id 上限值为int64,tiflash中错误的将region_id 解析为int32,导致region_id 达到 int32的值后,后续的新表设置的tiflash副本不能同步,已经设置tiflash的表不影响
相关issue:
https://github.com/pingcap/tidb/issues/37862

检查确认方式:
1、 检查PD 监控中alloc_id 或information_schema.tikv_region_peers中 region_id是否超过int32的最大值。

临时解决措施
应用hot fix : https://github.com/pingcap/tidb/issues/37862。 升级到修复版本

修复版本
预计6.5、6.1.4版本修复

可参考:
https://asktug.com/t/topic/996666/29

2 个赞

我们新发现了一个TiDB 的“BR”组件相关 critical bug,详细见下:

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

Issue

BR v6.4.0 的一个优化意外地引入了一个 BUG (https://github.com/pingcap/tidb/issues/40177),这个 BUG 可能导致某些分区表在恢复之后使用有问题的 Partition ID。

“有问题”体现在:那些 Partition ID 在日后还可能会被其他 Table 用作 Table ID。

Root Cause

BR v6.4.0 引入了在恢复的时候尝试保持旧集群的 Table ID 不变的优化,这个优化的基本流程如下:

  1. 在备份档案使用的所有 Table ID 中找到最大的 ID。
  2. 将 TiDB 的 Global ID(可以理解成 Table ID 所使用的的自增 ID)给 rebase 到这个最大的 ID。

在执行了 (2) 之后,理论上我们就可以安全地使用旧集群的 Table ID 了(因为这些 ID 并不会被再度使用)。

但是现有的实现在步骤 (1) 中,意外地忽略了分区表中的 Partition:Partition ID 也来自 Global ID,并且可能大于 Table ID。我们只把 Global ID rebase 到了 Max(TableID) 的话,无法保障这些 Partition ID 也能被安全地使用。

当任意一个 Partition ID 大于最大的 Table ID 的时候,问题就会出现了。

Diagnostic Steps

取决于这些“有问题”的 Partition 日后被如何使用,这个 bug 具体的的表现形式非常多,绝大多数表现形式都是毁灭性的,例如:

  • 分区表的数据被意外 GC。
  • 分区表的数据被意外覆盖。
  • 某些新表出现不该存在的记录。

另一种方法能更精确地判断这个 bug 有没有触发:

首先,在 BR 日志中查询 “registering the table IDs”,你会得到这样的日志:

[INFO] [client.go:244] ["registering the table IDs"] [ids="ID:[79,153)"]

这里,ids 表示了 BR 已经认为可以“安全使用”的 Global ID 区间,接下来,使用这个 SQL 查询。

SELECT T.`TIDB_TABLE_ID`, P.`TIDB_PARTITION_ID`, T.table_schema, T.`table_name`, partition_name FROM 
  INFORMATION_SCHEMA.`PARTITIONS` P INNER JOIN 
    INFORMATION_SCHEMA.`TABLES` T 
      ON (T.TABLE_NAME = P.TABLE_NAME and T.`TABLE_SCHEMA` = P.TABLE_SCHEMA) 
  WHERE T.`TIDB_TABLE_ID` BETWEEN @lower AND @higher;

将上面的 @lower@higher 替换成上面日志中 ids 表示的区间即可。

如果出现了某个 TIDB_PARTITION_ID 不在 ids 的区间内,那么这个 bug 大概率已经被触发,请参考下文 “Workaround”。

Resolution

我们在 v6.5.0 LTS 中发现并修复了这个问题。现在 BR 会将 Global ID 给 rebase 到 Max(TableID ∪ PartitionID)以避免该问题的发生。

Workaround

建议不要使用 v6.4.0 的 BR 进行分区表的恢复,可以使用 v6.5.0 LTS

如果一定要使用 v6.4.0 进行恢复,那么在该 bug 触发之后,可以通过 DROP 掉所有已经恢复的库表,并重新执行恢复来 workaround。

[Critical bug] v6.3.0-v6.5.0 使用 Multi-schema change 添加唯一索引导致数据索引不一致

产品 TiDB
组件 TiDB
版本 6.3.0 6.4.0 6.5.0

Issue

使用 multi-schema change 添加唯一索引后,唯一索引的状态未能正确设置,导致后续执行 INSERT IGNORE 语句时会不正确地插入了重复的行,破坏了索引的唯一性约束。例如:

create table t (a int, b int);
insert into t values (1, 1);
insert into t values (2, 2);
alter table t add unique index idx(b), ...[any other schema changes];
insert ignore into t values (2, 2);
admin check table t;

ERROR 8223 (HY000): data inconsistency in table: t, index: idx, handle: 2, index-values:"handle: 3, values: [KindInt64 2]" != record-values:"handle: 2, values: [KindInt64 2]"

目前仅在 INSERT IGNORE 语句上发现此类违反唯一性约束的 bug。使用 INSERT、UPDATE 和 REPLACE 语句来插入唯一索引重复值,都会按照预期报 “duplicate entry” 的错误。

Root Cause

TiDB 从 6.3.0 起,支持使用 ingest 模式 (@@tidb_ddl_enable_fast_reorg) 添加索引。在增量数据合并回原索引的步骤完成后,multi-schema change 对目标索引的状态的更改未持久化到 TiKV,而执行下一个 schema 变更时丢弃了这个更改。在整个 multi-schema change 的 DDL 完成后,目标索引始终处于不正确的状态。

假如应用后续执行 INSERT IGNORE 语句,TiDB 在判断索引值是否重复时,该索引的状态影响了判断逻辑,导致检查被忽略,插入了重复的值(正常情况是不插入重复值并报 warning)。

Diagnostic Steps

出现数据索引不一致后,如果同时符合以下几种条件就可以确认是同一问题:

  • TiDB 版本为 6.3.0、6.4.0 或 6.5.0。
  • 检查该表的 DDL 历史记录,使用过 multi-schema change 添加唯一索引。
  • 数据索引不一致涉及到的索引和 multi-schema change 添加的索引是同一个索引。
  • 搜索 TiDB 添加唯一索引时间段的日志,包含 “[ddl-ingest]” 关键字。

Resolution

我们将在 v6.5.1 LTS 中修复这个问题。

Workaround

建议不要使用 multi-schema change 添加唯一索引。如果已经添加,最好重建索引以避免日后出现数据索引不一致。