lightning导入数据，checksum失败，表实际数据和count(*)不一样

🪐 TiDB 技术问题
1

【TiDB 使用环境】测试
【TiDB 版本】8.1.2
dumpling从8.1.1导出单库数据
用lightningv8.1.2导入到8.1.2 tidb中，3个tidb节点
lightning单线程多线程都试了，db中的表随机出现同样问题。

create table buy_statistics_copy like buy_statistics（出问题的表）;
insert into buy_statistics_copy select * from buy_statistics;–成功复制，提示“7814105 rows affected”
select count() from buy_statistics_copy; – 结果7814105
select count() from buy_statistics; --结果7850823

lightning错误信息如下：
[ERROR] [import.go:175] [-] [table=business.buy_statistics] [status=checksum] [error=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 4725871743356335951 vs 8644857220378243416) (total_kvs: 15664928 vs 15999798) (total_bytes:919035234 vs 939367460)”]

2

学习下

3

坐等大佬解答！

1 个赞
4

不应该啊，count出来的数据量是最真实的数据量。是否每次统计count是彻底写入前执行的呢，会不会是一些线程还在写入就开始执行count了？

1 个赞
5

大概率是 Lightning 导入时的 “数据写入 / 校验逻辑与 TiDB 集群状态不兼容”

6

若表存在 二级索引、分区表结构 ，或导入后 TiKV 正在做后台 Compaction / 索引同步，TiDB 计算集群侧 checksum 时可能 “未包含部分异步写入的数据”，导致校验值不匹配。

7

或者将Dumpling 升级到与 Lightning 一致的 8.1.2 版本，再重新导入数据试试

8

谢谢大家回复，目前看是lightning导入数据时候， index和table数据不一致导致。 删除index后重建，count（*）会发生变化，展示真实数据量

每次导入测试，出现问题的表不一样， 有时候是index数据>table数据，有时候table数据> index数据

原因是什么不知道。
Create Table: CREATE TABLE buy_statistics (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
day varchar(11) NOT NULL,
aid bigint(20) DEFAULT NULL,
vid bigint(20) DEFAULT NULL,

auto_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (id) /*T![clustered_index] CLUSTERED */,
KEY index_day_from (vid,aid,day)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

mysql> admin check table buy_statistics;
ERROR 8223 (HY000): data inconsistency in table: buy_statistics, index: index_day_from, handle: 15246922, index-values:“” != record-values:“handle: 15246922, values: [KindInt64 484461004 KindInt64 0 KindString 20231011]”

mysql> select count() from buy_statistics;
±---------+
| count() |
±---------+
| 4967646 |
±---------+
1 row in set (0.01 sec)

mysql> alter table buy_statistics drop key index_day_from;
Query OK, 0 rows affected (0.27 sec)

mysql> alter table buy_statistics add key index_day_from (vid,aid,day);
Query OK, 0 rows affected (11.60 sec)

mysql> select count() from buy_statistics;
±---------+
| count() |
±---------+
| 5001041 |
±---------+
1 row in set (4.52 sec)

1 个赞
9

Lightning 导入数据校验失败了？

10

是的，提示校验失败，日志如下
[2025/11/17 09:58:13.945 +08:00] [ERROR] [import.go:175] [-] [table=business.buy_statistics] [status=checksum] [error=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 13707461141405198035 vs 10702470403205320274) (total_kvs: 9968687 vs 10002082) (total_bytes:1525280312 vs 1528441670)”]
[2025/11/17 09:58:13.961 +08:00] [INFO] [client.go:347] [“[pd] http client closed”] [source=lightning]
[2025/11/17 09:58:13.961 +08:00] [ERROR] [main.go:105] [“tidb lightning encountered error stack info”] [error=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 13707461141405198035 vs 10702470403205320274) (total_kvs: 9968687 vs 10002082) (total_bytes:1525280312 vs 1528441670)”] [errorVerbose=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 13707461141405198035 vs 10702470403205320274) (total_kvs: 9968687 vs 10002082) (total_bytes:1525280312 vs 1528441670)\ngithub.com/pingcap/errors.AddStack\n\t/root/go/pkg/mod/github.com/pingcap/errors@v0.11.5-0.20240318064555-6bd07397691f/errors.go:178\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\t/root/go/pkg/mod/github.com/pingcap/errors@v0.11.5-0.20240318064555-6bd07397691f/normalize.go:175\ngithub.com/pingcap/tidb/lightning/pkg/importer.(*TableImporter).compareChecksum\n\t/workspace/source/tidb/lightning/pkg/importer/table_import.go:1377\ngithub.com/pingcap/tidb/lightning/pkg/importer.(*TableImporter).postProcess\n\t/workspace/source/tidb/lightning/pkg/importer/table_import.go:1102\ngithub.com/pingcap/tidb/lightning/pkg/importer.(*Controller).importTables.func7.1\n\t/workspace/source/tidb/lightning/pkg/importer/import.go:1864\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1650”]

11

是表数据有改变导致的吗

12

这种就是表和索引不一致导致的，实际表数据没问题，索引有问题，然后查询的时候用到了索引，所以显示不一致，可以把索引重建下

13

索引重建后一致了，但是当索引数据多，表数据少的时候， 重建也不解决问题，导入的时候数据就丢了。

14

lightning导入，存在表数据不全，索引数据全的情况 或者是表数据全，索引缺失的情况， 出现问题的表随机。 是否能调整lightning参数来解决？ 还是bug？

15

一般表和索引不一致都是表的类型比较特殊，或者触发bug导致，正常不会有这种情况的。一般都是表数据全，索引数据不全或者多吧，原表和目标表数据也不一致吗？

16

对的，有出现目标表实际数据少于原表的情况。
这个集群之前反复做过测试，删除库，导入数据，没有出现问题。
现在准备上线做最后一次数据同步的时候发生的

17

普通的表，可以看上面的建表sql，索引如下：
PRIMARY KEY (id ) /*T![clustered_index] CLUSTERED */,
KEY index_day_from (vid ,aid ,day )

18

问题原因基本找到了，是disk-quota = 160000设置过小导致的，开到10G，再导入就正常了。

19

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。