mysql 迁移 tidb 主键自增变大，甚至超过int类型最大值

🪐 TiDB 技术问题 备份&数据迁移
1

mysql 迁移 tidb后，主键自增变大，甚至超过int类型最大值

2

TiDB 的自增主键是由 PD 预分配给每台 TiDB server 的 ，每台 tidb 会事先得到一段 自增 id 。当本地缓存的自增 id 用完后会，再次向 PD 申请全局最大的 自增 ID，如果在数据写入时，

  • 如果有显示的写入的自增 ID，和隐式的使用自增 ID。会造成自增 ID 跳跃。
  • 或者多个 tidb server 没有使用 LB 来均分写压力也会造成 自增 ID 的跳跃。
3

tidb是全新的环境，之前没有数据，完全从mysql迁移过来的，采用dumping导出，lightning导入,导出的auto_increment=37797049导入后直接超过int类型最大值，还没有任何操作

4

请将表结构与相关报错截图，已经 tidb 的日志一并发出，来看下具体问题。

5

原表表结构：
CREATE TABLE s_log (
id int(11) NOT NULL AUTO_INCREMENT,
user_id varchar(50) DEFAULT NULL,
user_name varchar(50) DEFAULT NULL,
url text DEFAULT NULL,
params text DEFAULT NULL,
handling_time varchar(50) DEFAULT NULL,
create_time timestamp DEFAULT CURRENT_TIMESTAMP,
data_origin varchar(10) NOT NULL DEFAULT ‘bi’ COMMENT ‘log来源’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=37797049

迁移后：
CREATE TABLE s_log (
id int(11) NOT NULL AUTO_INCREMENT,
user_id varchar(50) DEFAULT NULL,
user_name varchar(50) DEFAULT NULL,
url text DEFAULT NULL,
params text DEFAULT NULL,
handling_time varchar(50) DEFAULT NULL,
create_time timestamp DEFAULT CURRENT_TIMESTAMP,
data_origin varchar(10) NOT NULL DEFAULT ‘bi’ COMMENT ‘log来源’,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=2550279433
迁移后，AUTO_INCREMENT 超过int最大值

6

这时还没有业务操作，在检测数据是发现问题

7

Get schema Information about db.table, and you can get schema info by tableID (tableID is the unique identifier of table in TiDB)

curl http://{TiDBIP}:10080/schema/{db}/{table}

使用如上 API 拿下 相关信息

并检查下 s_log 的 当前 ID 最大值是多少

以及确认 lightning 导入后 此表的 checksum 是否是正常的

8

当前表id最大值，和mysql的最大值一样，没有超，不只这一张表有这情况，其它表也有，不是所有都有问题，搞不明白

13

请拿下

  • curl http://{TiDBIP}:10080/schema/{db}/{table} 相关信息

  • 以及检查 lightning 的导入日志 ，确认表的 checksum 是否正确

15

report_gov_hall_movie_box_cinema_day.txt (33.2 KB)
这是另一张表的，其它日志都清了

17

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%87958×495 13.2 KB

18

如果没有相关日志不好进行判断
如果目前在重新进行数据导入
再次出现同样问题，建议反馈下 具体的日志，以及相关步骤

19

重新导入，没有复现，不知道这是什么情况

20

即使重新导入，没有出现这种情况，线上也不敢这么用，自增变大后，还能 改下，线上突然出现这种情况，改都没办法改，auto_increment 只能改大，不能往小的改，致命的问题

21

从现在情况看，更大的可能在 lightning 导入阶段出现了一些问题，因为没有日志不能进行确认。
有关 auto_increment 不能修改到较小值，这个情况我们会作为一个需求进行记录。

另外提供一个官方的建议与其他用户的经验
1.TiDB 的 自增 ID 因为是预先分片的，每台 tidb 会预先分配 30000 个不重复的 ID，所以 ID 消耗会较大，同时为了打散热点 也提供了新的 自增 ID 类型 auto_random。因此更建议自增 ID 使用 bigint
可以参考：https://docs.pingcap.com/zh/tidb/stable/auto-increment
2.lightning 在数据导入前可以手动创建 新的表结构进行一定的调整，后面再通过 lightning 进行数据导入
可以参考：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-faq#我已经在下游创建好库和表了tidb-lightning-可以忽略建库建表操作吗

22

好的，谢谢

23

:ok_hand: