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同步进度不更新。
影响版本
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)
现象和确认方法
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在 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
Bugfix PR: https://github.com/tikv/tikv/pull/11904
修复版本：5.0.7, 5.1.4, 5.3.1, 5.4.0
| 产品 | TiDB |
|---|---|
| 组件 | PD TiKV |
| 版本 | 5.4.2 5.3.2 |
| 分类 | Troubleshoot |
| 标签 | KnowIssue |
| 来源 |
在对 PD 进行 Transfer Leader 或重启操作后，集群出现 SQL 执行持续报错的现象。
6.2.0 测试中发现了该问题：https://github.com/tikv/tikv/issues/12934
受到该 bug 影响的版本：v5.3.2, v5.4.2
TiDB 监控观察到 SQL 执行持续报错，报错为 Region Unavailable / Region Epoch not match 等
TiKV 监控中 TiKV Details - PD - PD heartbeats 中观察到持续快速上涨的 pending
升级 TiKV 至修复了该 Bug 的版本。
Bug Fix PR: https://github.com/tikv/tikv/pull/13094
预期修复版本：v5.3.3, v5.4.3
| 产品 | TiDB |
|---|---|
| 组件 | TiFlash |
| 版本 | 6.1.0 |
| 分类 | Troubleshoot |
| 标签 | KnowIssue |
| 来源 |
TiFlash 在运行中偶尔出现某些系统调用（诸如 write()）返回非法的 errno，由于程序无法处理非法 errno，所以最终会导致进程崩溃。由于仅在开启 Profiling 期间复现出该问题，因此怀疑与 Profiling 相关。
Github issue: https://github.com/pingcap/tiflash/issues/5687
在 TiDB Dashboard 关闭 Continuous Profiling，并且暂时不要在对 TiFlash 进行 Manual Profiling。
NOTE: 目前只有 v6.1.0 和 v6.2.0 版本默认开启 Continuous Profiling，我们从 v6.1.1 版本开始默认关闭 Continuous Profiling。
| 产品 | TiDB |
|---|---|
| 组件 | TiDB |
| 版本 | 6.1.0 |
| 分类 | Troubleshoot |
| 标签 | KnowIssue |
| 来源 |
https://github.com/pingcap/tidb/issues/37238
当 tidb_enable_outer_join_reorder 设置为 true 时，
join reorder 处理过程中对 join 的 ON condition 处理有误
当存在多个 outer join，各自的 ON condition 中的条件比较简单，只涉及不多于两个表，而且涉及了多个 outer join 的公共外表时，其结果有可能出错。
修复 pr https://github.com/pingcap/tidb/pull/37245
修复版本 6.1.1 6.2.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版本修复
问题
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版本修复
我们新发现了一个TiDB 的“BR”组件相关 critical bug，详细见下：
| 产品 | TiDB |
|---|---|
| 组件 | BR |
| 版本 | 6.4.0 |
| 分类 | Troubleshoot |
| 标签 | KnowIssue |
| 来源 |
BR v6.4.0 的一个优化意外地引入了一个 BUG (https://github.com/pingcap/tidb/issues/40177)，这个 BUG 可能导致某些分区表在恢复之后使用有问题的 Partition ID。
“有问题”体现在：那些 Partition ID 在日后还可能会被其他 Table 用作 Table ID。
BR v6.4.0 引入了在恢复的时候尝试保持旧集群的 Table ID 不变的优化，这个优化的基本流程如下：
在执行了 (2) 之后，理论上我们就可以安全地使用旧集群的 Table ID 了（因为这些 ID 并不会被再度使用）。
但是现有的实现在步骤 (1) 中，意外地忽略了分区表中的 Partition：Partition ID 也来自 Global ID，并且可能大于 Table ID。我们只把 Global ID rebase 到了 Max(TableID) 的话，无法保障这些 Partition ID 也能被安全地使用。
当任意一个 Partition ID 大于最大的 Table ID 的时候，问题就会出现了。
取决于这些“有问题”的 Partition 日后被如何使用，这个 bug 具体的的表现形式非常多，绝大多数表现形式都是毁灭性的，例如：
另一种方法能更精确地判断这个 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”。
我们在 v6.5.0 LTS 中发现并修复了这个问题。现在 BR 会将 Global ID 给 rebase 到 Max(TableID ∪ PartitionID)以避免该问题的发生。
建议不要使用 v6.4.0 的 BR 进行分区表的恢复，可以使用 v6.5.0 LTS 。
如果一定要使用 v6.4.0 进行恢复，那么在该 bug 触发之后，可以通过 DROP 掉所有已经恢复的库表，并重新执行恢复来 workaround。
| 产品 | TiDB |
|---|---|
| 组件 | TiDB |
| 版本 | 6.3.0 6.4.0 6.5.0 |
使用 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” 的错误。
TiDB 从 6.3.0 起，支持使用 ingest 模式 (@@tidb_ddl_enable_fast_reorg) 添加索引。在增量数据合并回原索引的步骤完成后，multi-schema change 对目标索引的状态的更改未持久化到 TiKV，而执行下一个 schema 变更时丢弃了这个更改。在整个 multi-schema change 的 DDL 完成后，目标索引始终处于不正确的状态。
假如应用后续执行 INSERT IGNORE 语句，TiDB 在判断索引值是否重复时，该索引的状态影响了判断逻辑，导致检查被忽略，插入了重复的值（正常情况是不插入重复值并报 warning）。
出现数据索引不一致后，如果同时符合以下几种条件就可以确认是同一问题：
我们将在 v6.5.1 LTS 中修复这个问题。
建议不要使用 multi-schema change 添加唯一索引。如果已经添加，最好重建索引以避免日后出现数据索引不一致。
| 产品 | TiDB |
|---|---|
| 组件 | TiDB |
| 版本 | 6.0.0 6.1.1 6.1.2 6.1.3 6.1.4 |
https://github.com/pingcap/tidb/issues/41581
TiDB 使用 RC 隔离时，point get executor 读取的时间戳没有按预期刷新，取不到最新的值。使用RC隔离级别时，执行者不会获取不存在的key的悲观锁，更新可能不会对新插入的行生效。
如果更新结果出乎意料，例如不会更新最新值。尝试确认：
pointGetExecutor读取在update/delete语句之前使用select for update锁定row key
禁用 RC 隔离级别，改用默认的 RR
这个帖子很相近
集群版本：5.0.4
[Critical bug] Log Backup 在遇到 TiKV 重启后可能会遗落数据
新发现了一个TiDB 的“TiKV BR”组件相关 critical bug，详细见下：
| 产品 | TiDB |
|---|---|
| 组件 | TiKV BR |
| 版本 | 6.5.4 7.1.0 7.1.1 7.4.0 7.2.0 7.3.0 7.1.2 7.5.0 6.5.6 7.1.3 6.5.5 7.1.4 7.5.1 7.6.0 6.5.7 6.5.8 8.0.0 6.5.9 |
| 分类 | Developer |
| 标签 | KnowIssue |
| 来源 |
Issue
https://github.com/tikv/tikv/issues/16809
Root Cause
TiKV 在日志备份的时候会启动两个并行的进程：
一个用于推进备份的进度，这个进程会从 PD 不断地获取最新的 TSO，并且用它计算备份最新的进度。
在进程 (1) 积攒了足够多的文件之后，它会将当前缓存的文件上传到外部存储。在此之后，它会从 (2) 中获得当前的进度，并且更新到 PD 上。
但是，在 (1) 将文件上传到外部存储的过程中，新的写入将会持续进入，并且被计入进度计算；问题出现在这里：这些新的写入不会在当前批次中被上传到外部存储。因此，假如 (2) 在 (1) 上传文件的过程中，计算了最新的进度，那么这个进度其实是“超前”的。
一般情况下，这些写入会和下一批一起被上传，此时这个“超前”的进度并不会造成严重的后果。但是，如果 TiKV 此时因故重启，这批数据就会丢失。如果此时全局 Checkpoint 已经推进，其他 TiKV 在成为 Leader 之后会从这个“超前”的进度开始日志备份。此时前面提到那些未被备份的数据将永远不会被备份。
[1,Flush] [2,calculate progress]
TS --------------|----------|-------->
^ ^
| ± …but the log backup believes we have backed up to here
± Writes was actually backed up to here…
目前触发概率没有很精准的方式估算，但是总体上看，触发概率：
随着 Flush 花费时间的上升而上升。
随着 TiKV 数量上升而下降。（因为有更多 TiKV 的时候，全局 checkpoint 被某个 TiKV 卡住的概率会变大。）
考虑到 TiKV 重启并不常见，而且目前 PiTR 本身也要求周期性重新全量备份，总体上看这个 bug 触发概率并不算高。
Diagnostic Steps
目前在备份集群没有很好的手段来发现这个问题。
这个问题遗失数据一个比较明显的特征是，那些被遗失的数据在某次进度更新之前，大约几百毫秒内的写入的。可以通过检查数据行的时间戳或者通过 TiDB HTTP API 查询 MVCC 版本确认。
Resolution
触发之后增量备份的部分数据会丢失，目前无法找回。
建议参考 workaround 部分或者升级到不受影响的版本。(6.5.10, 7.1.5, 7.5.2, 或者更高的 LTS 版本。)
以下 LTS 版本受到了影响:
Release 6.5: 6.5.4~6.5.9
Release 7.1: 7.1.0~7.1.4
Release 7.5: 7.5.0~7.5.1
Workaround
在上游集群，可以设置 log-backup.min-ts-interval （这个配置项没有文档）到大于全量备份间隔的值（例如，365d）来解决这个问题；但代价是 RPO 可能在 Leader Transfer 比较频繁的情况下会低于预期。
[Critical bug] 使用 restore 恢复带 auto random 字段的表, 可能导致数据修改错误
大家好，
我们新发现了一个TiDB 的“BR”组件相关 critical bug，详细见下：
| 产品 | TiDB |
|---|---|
| 组件 | BR |
| 版本 | 6.4.0 6.5.0 6.5.1 6.5.2 6.5.3 6.5.4 7.1.0 7.1.1 6.1.5 6.1.6 6.1.7 7.0.0 7.4.0 6.6.0 7.2.0 7.3.0 7.1.2 7.5.0 6.5.6 7.1.3 6.5.5 7.1.4 7.5.1 7.6.0 6.5.7 6.5.8 8.0.0 |
| 分类 | Troubleshoot |
| 标签 | KnowIssue |
| 来源 |
Issue
使用 br restore 恢复出来的集群上, 执行 insert on duplicate key update 语句, 可能会遇到错误的目标记录被修改的情况.
Root Cause
如果表的主键是一个包含 auto random id 在内的组合索引, 这个表在 br 恢复后的集群上, auto random id 字段不会被 rebase. 后续对这张表的 insert on duplicate key update 语句会因为生成的 id 与已经存在记录的 id 重复, 产生非预期的对老记录的更新, 导致数据出错.
Github Issue br doesn't rebase auto random if table's PKIsHandle is false · Issue #52255 · pingcap/tidb · GitHub 参看这个 issue 里面的复现的例子.
Diagnostic Steps
可以通过下面的方法来诊断这个问题的存在
检查集群中是否有表的主键是包含 auto random id 的组合索引，并且该表的数据是通过 BR restore 生成的。没有就跳过, 否则, 执行步骤 2
对包含 auto random id 字段的复合主键的表, 执行 show create table 语句, 观察输出结果 AUTO_RANDOM_BASE 的值是否正常
Resolution
该问题在最新的版本中已经修复，以下是受到该问题影响的 LTS 版本，可以考虑升级到 6.1.8, 6.5.9, 7.1.5, 7.5.2 及之后的版本以避免该问题。
v6.1.5-v6.1.7
v6.5.0-v6.5.8
v7.1.0-v7.1.4
v7.5.0-v7.5.1
Workaround
参照源集群, 使用 alter table auto_random_base 语句修复受影响的表
点赞 ，很及时！
我们还真有这个使用场景
mark 来收藏一下这个帖子