【 TiDB 使用环境】生产\测试环境\ POC
【 TiDB 版本】
v5.4.0
【遇到的问题】
tiup cluster upgrade tidb-test v5.4.1时，报错
日志中
目前集群状态如下
【复现路径】做过哪些操作出现的问题
【问题现象及影响】
应该是版本升级跨度大导致的
日志里看启动tidb启动版本是v6.1.0
5.4升级到6.1 版本跨度也不大呀。问题不在这
第一次升级到v5.4.1报错了，然后就尝试升级到v6.1.0然后还是一样报错。
根据报错是系统表没有创建
升级的版本 跟日志也对不上。
命令是升级到5.4.1
结果tidb启动是6.1.0
盲猜跟版本错乱有关系，每个版本升级都有补丁应该是补丁里的建表语句没有执行
有点奇怪 刚才看了启动脚本的源码 bind_info这张表3.0版本左右就有了。并且后续升级没有删除重建的动作，只有更新表数据或者升级表结构。 造成问题的是启动脚本检查升级过程中执行了更新bind_info表数据 ，但是库里又没有那张表。
升级了两次
第一次是升级到v5.4.1没有成功，报错了
第二次是升级到v6.1.0也是报错
这个bind_info表在v5.4.0中就存在，但是升级却报没有，
个人也猜是：
在升级时，有什么操作在运行，因为我在tidb-server日志中发现有create table的行为，升级版有新加系统表是正常的
还有一种可能是要修改已经存在的系统表，比如给它加或是修改字段
不知道跟这个有没有关。 表给升级丢了就很神奇。 而且就算按照脚本创建表也没意义还得有数据。
文档上说的 执行ddl语句过程中升级会出现“行为未定义”不知道什么意思。 目前根据日志和源码仅仅能分析出报错原因 ，如何造成的看看官方有没有案例解答吧。 目前看 5.4升级6.1应该是没问题。 除非是3.0之前的版本升级 才会涉及到bind_info的建表操作
目前我们怎么修复呢，是否可以从别的tikv拷贝过来这个数据，数据库全都启动不起来了，着急
如果表不是内存表，那丢不了，要不就是，如果有取消ddl操作，在这过程中有删除
您好，确认一个情况，在第一次，也就是 5.4.0 升级到 5.4.1 的之后，就报 mysql.bind_info 找不到了是吗？
麻烦提供一下 tidb-server 的日志，方便排查问题，辛苦。
我们重做了，日志拿不到了。
好的，请问可以提供 bind_info 表内容吗？如果方便提供请记得脱敏，多谢
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。