【 TiDB 使用环境】生产环境
【 TiDB 版本】V5.4.3
【复现路径】
- 误删数据库比如 ： goods 数据库
- 禁用 tikv gc : SET GLOBAL tidb_gc_enable = OFF;
- 设置快照时间点 ： set @@tidb_snapshot=“xxxx-xx-xx xx:xx:xx”;
- 发现被误删的 goods数据库还在
- 使用br 工具进行备份，备份的时候指定 --backupts 为 快照 ts
- 备份成功后将备份的 goods库恢复到生产环境
- 清理快照时间点 ： set @@tidb_snapshot=“”;
- 开启 tikv gc : SET GLOBAL tidb_gc_enable = ON;
【遇到的问题：问题现象及影响】
数据库恢复以后，业务开始写入数据，此时有主键冲突，发现 auto_increment 的值从1开始了。
由于当时情况紧急，使用 ALTER TABLE table_name AUTO_INCREMENT =xxx 解决了。
我的问题是：
- br还原后，为什么 auto_increment 会从1 开始？
- 因为库中的表特别多， ALTER TABLE table_name AUTO_INCREMENT =xxx 虽然可以解决，但是太麻烦，有没有简单的办法解决这个问题？ 平滑重启 tidb server 是否能让 tidb 根据表的max ID，重启分配ID段，来解决这个问题
正常不应该有这个问题吧，表结构里面自带的有AUTO_INCREMENT字段啊。。。
stephanie
(Ti D Ber H D Noxetz)
10
auto_increment不是缓存在每个tidb，不会持久化的吗？那br恢复的时候会对这个做处理吗？
zhanggame1
(Ti D Ber G I13ecx U)
11
理论上不需要持久化,tidb启动时候再分一段就行，有些自增值虽然没用但也被抛弃了不用了
升级到6.5.9吧，我理解重启应该也不能解决这个问题，应该是没有正常重置成功。重启只是把现有的缓存清了，加大的不一定符合。
小龙虾爱大龙虾
(Minghao Ren)
15
小王同学Plus
(小王同学 Plus)
16
应该是有几个类似的 bug 需要注意：
一个是楼上提到的这个 Duplicate entry when using BR to restore a NONCLUSTERED AUTO_ID_CACHE=1 table · Issue #46093 · pingcap/tidb · GitHub
- nonclustered 表的话会有一个 auto increment 的隐藏列 _tidb_rowid，当 nonclustered 表同时存在auto_id_cache=1 的 auto increment 列的情况下，lightning/br 导入后，会丢失 _tidb_rowid 的一部分metadata(auto_increment的具体值)。
- 经过 lighting/br 导入后，表中用户定义的自增列和 _tidb_rowid 的 metadata 混在一起，造成两个在show table 里观察到的值都不正确。同时因为 metadata 不正确，所以无法正确发号，会造成 duplicate entry 的 error。
还有一个是 DDL lost history jobs after batch creating tables · Issue #43725 · pingcap/tidb · GitHub
- 当 BR restore 执行 batch create table 遇到 “entry too large, split batch create table” 报错时导致部分表创建失败，后续 BR 在 split batch 重试 batch create table 时发现这些表已经存在就直接返回错误了，不会走到后续更新 auto id 的逻辑，最后重新分配 auto id 会出现主键冲突的现象。
- TiDB 日志中出现执行 “create tables” 时报 ErrEntryTooLarge 错误。检查 admin show ddl jobs，某个建表 DDL job 被 cancel，但实际上执行成功（比如能通过 show create table 获取到表信息）。
升级是比较好的处理方式，不然 workaround 可能就是 alter table auto_increment = x 手动重置 auto id
1 个赞