rename 表名后，应用端需要重新建立连接才能保持访问原名的表吗？

🪐 TiDB 技术问题
1

由于一些特性不能在线 alter 表 a，所以就创建了新表 a_new，然后执行操作：
rename table a to a_x, a_new to a;
…
truncate table a_x;
drop table a_x;

发现应用还是会继续访问改名后的表 a_x，但 a_x 已经删除，所以报错。

我的问题就是上述更新表的操作，需要应用端重新建立连接才能反问新的表吗？

有知晓的吗？

多谢了先👍

2

没有明白,你说的rename只是修改了数据库的表名,应用端也需要修改表名访问才行啊

3

测试了下，8是没问题的

4

测试下flush privileges;有效果没有

5

没遇到过这种情况，应用端访问的还是A表

6

应该还是访问a表呀

7

a表都被删除了，应用需要改sql查询备份表

8

TiDB 兼容 MySQL 的会话元数据缓存机制：

  • 应用程序与数据库建立连接（Session）后，第一次访问表 a 时，该连接会缓存「表名 a → 实际表对象（物理 ID）」的映射关系；
  • 当你执行 rename table a to a_x, a_new to a 后，新的连接会读取最新的元数据，访问的是新表 a；
  • 但已存在的旧连接仍使用缓存的映射（认为 a 对应的是原来的表对象，也就是改名后的 a_x），因此继续访问 a 时，实际访问的是 a_x，直到该连接关闭 / 元数据缓存失效。
9

看上去是这样👍，那么这种情况怎么处理好，执行 rename 操作后，TiDB 上 kill 掉连接相关库的 process？应用端检测到相关错误重连？如果靠应用端检测的话，就需要 TiDB 文档里有明确的需要重连的错误号指导了。

10

如果要这样，就不能随便reaname了

11

很奇怪，这个成已经把新表名rename成老表名了，怎么还没查之前的表呢

12

不可能吧，访问肯定是访问新表啊

13

应用建立连接时，会将表名（a）与实际物理表（a_x）的映射关系解析并缓存到连接的上下文里。后续执行 rename table 后，缓存中的映射关系仍是旧表名 a_x，但该表已被删除，导致报错。

14

但我还是认为合理的做法应该是在 TiDB 端就处理好 rename 的后续操作，而不是让潜藏的影响、问题流转到应用端。

15

你用应用引用新表名访问啊

16

应用端并没有改变访问的表名，而是 TiDB 里的表被其它渠道比如 DMS 修改了，但应用端却还是访问修改了名称后的表。

17

补充些信息，使用的 8.5.3 版本，问题并不是必现的，似乎 rename 的操作不是原子操作时，更有可能发生。如：
rename table a to a_x;
rename table a_new to a;
…
truncate table a_x;
drop table a_x;

18

不用的，但是估计需要等到pd刷新表的元数据之后才能正常操作

19

看官方文档是原子的呢