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