升级前有没有 admin show 检查 ddl 执行情况呢 https://docs.pingcap.com/zh/tidb/stable/upgrade-tidb-using-tiup#25-检查当前集群的-ddl-和-backup-情况 ，看上去是卡在获取 version=130240 这个 schema version 了，可以发一下升级前后的完整 tidb 日志

这里的 hint 提到了，不过对于其他涉及多个 table 的 hint 应该也适用，可以优化下文档 [image]

有个类似的 issue：https://github.com/pingcap/tidb/issues/38245

升级上来的么，新部署的 v6.1.2 集群没这个问题

检查一下表上还有没有数据索引不一致的情况 https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-check-table-index#admin-check-tableindex

那应该是 v5.x 版本存在的问题，BR 备份恢复时也不会检查数据不一致，之前版本存在一些 bug 会导致在某些情况下没有删除索引 key；上面报错提示索引数据数量要比记录数据数量多，可以先清理多余的索引数据，建议将 tidb_enable_mutation_checker 参数打开，避免再遇到这类问题 admin cleanup index [table_name][index_name];

当前 v6.2 集群是从之前哪个版本升级上来的吗，从 v6.0 开始，一致性检查的参数 tidb_enable_mutation_checker 是默认开启的，如果遇到 8133 报错会回滚 DML 语句

上面的报错看上去像是配置的问题，可以发一下启动失败后完整的日志吗

也可能是 tidb binlog 没有开启，或者 tidb server 写 binlog 报错之后不再写 binlog 了 https://docs.pingcap.com/zh/tidb/stable/tidb-binlog-faq#主从同步开启-ignore-error-触发-critical-error-后如何重新部署

可以查查 cluster_hardware 视图 disk 相关信息

https://github.com/tikv/tikv/issues/12934 这个 bug 只影响 v5.3.2 和 v5.4.2 版本 升级时 io util 100% 是 tikv-server 占用的吗，有没有看 iotop，系统 message 和 dmesg 有没有报错

需要配置上 mysql 连接信息 [image]

可以查下 drainer.toml 参数配置 https://docs.pingcap.com/zh/tidb/stable/tidb-binlog-configuration-file#syncertocheckpoint

写入主要是 raftstore 线程 propoase/apply wait 长尾延迟高，可以按楼上建议的，根据当前 cpu 和 io 资源情况，先调大这两个线程池 [image]

可以导出这段时间的 TiDB、TiKV-Details、TiCDC 监控快照看看 https://docs.pingcap.com/zh/tidb/stable/exporting-grafana-snapshots

升级前 5.4.1 版本有遇到问题吗

除了升级 TiDB 版本，us3 是否做过什么变更，可以描述下这个 s3 的实现机制吗，我们在 aws s3 没遇到这个问题

备份到 TiKV 本地目录，会产生 tmp 文件吗

你好，代码相关问题的讨论可以在 github 上提个 Issue：Ask a Question，便于 RD 跟进回复，感谢支持~ https://github.com/pingcap/tidb/issues/new?assignees=&labels=type%2Fquestion&template=general-question.md