lighting导入报错checksum mismatched remote vs local

[扬仔_tidb (Ti D Ber I Ruk U8 Tg)]

【 TiDB 使用环境】生产环境
【 TiDB 版本】
源tidb:v5.3.0，新集群v:6.5.5
导出命令:tiup dumpling:v5.3.0 没报错正常
导入命令：tidb-lightning:v6.5.5 在最后报一张表校验错误
【遇到的问题：问题现象及影响】

1. 报错
   [2023/11/08 08:24:57.403 +08:00] [ERROR] [restore.go:1562] [“restore all tables data failed”] [takeTime=33h35m18.140456268s] [error=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 5082494353818434127 vs 4870243886886057165) (total_kvs: 1053425055 vs 1053425056) (total_bytes:182934745248 vs 182934745297)”]

[2023/11/08 08:24:57.403 +08:00] [ERROR] [restore.go:495] [“run failed”] [step=4] [error=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 5082494353818434127 vs 4870243886886057165) (total_kvs: 1053425055 vs 1053425056) (total_bytes:182934745248 vs 182934745297)”]

[2023/11/08 08:24:57.403 +08:00] [INFO] [restore.go:1200] [“everything imported, stopping periodic actions”]

[2023/11/08 08:24:57.403 +08:00] [ERROR] [restore.go:505] [“the whole procedure failed”] [takeTime=33h35m43.982662786s] [error=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 5082494353818434127 vs 4870243886886057165) (total_kvs: 1053425055 vs 1053425056) (total_bytes:182934745248 vs 182934745297)”]

[2023/11/08 08:24:57.403 +08:00] [ERROR] [restore.go:173] [“tables failed to be imported”] [count=1]

[2023/11/08 08:24:57.403 +08:00] [ERROR] [restore.go:175] [-] [table=scm.wxhc_logistics_order_detail] [status=checksum] [error=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 5082494353818434127 vs 4870243886886057165) (total_kvs: 1053425055 vs 1053425056) (total_bytes:182934745248 vs 182934745297)”]

[2023/11/08 08:24:57.419 +08:00] [INFO] [checksum.go:480] [“service safe point keeper exited”]

[2023/11/08 08:24:57.419 +08:00] [ERROR] [main.go:103] [“tidb lightning encountered error stack info”] [error=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 5082494353818434127 vs 4870243886886057165) (total_kvs: 1053425055 vs 1053425056) (total_bytes:182934745248 vs 182934745297)”] [errorVerbose="[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 5082494353818434127 vs 4870243886886057165) (total_kvs: 1053425055 vs 1053425056) (total_bytes:182934745248 vs 182934745297)\ngithub.com/pingcap/errors.AddStack\n\t/go/pkg/mod/github.com/pingcap/errors@v0.11.5-0.20220729040631-518f63d66

2. 检查wxhc_logistics_order_detail这张表的导出sql文件，我看最后几行已经进到新tidb集群了。
3. 请问要将wxhc_logistics_order_detail这张表重新导入吗？是不是导入的时候工具版本不对
   【资源配置】
   【附件：截图/日志/监控】

[扬仔_tidb (Ti D Ber I Ruk U8 Tg)]

新旧集群这个参数lower_case_table_names都是2

[有猫万事足]

物理模式导入的时候才会触发这个checksum。
我碰上的checksum不一致一般是以下几个原因：
1，导入的时候，有其他人写了这个表。
2，如果是增量导入，上次导入的数据的sql文件因为各种问题没有删除干净。导致再次导入的时候跟着又导入了一遍。也就是某一天的数据可能有两份（物理导入这种情况是无视索引限制的）

如果你确定就是最后一张表有问题。我觉得可以考虑去掉其他表的sql文件和safepoint，只尝试导入最后一张表试试。

另外再次运行lightning的时候，可能因为存在safepoint的原因，会让你使用lightning-ctl清理safepoint。要十分小心，看清提示的命令，不要一下清理到整个导入的其他表。如果真的不幸清理掉了，赶紧停掉目标库的gc，然后flashback删掉的表。（我这么误操作过一次 ）

[扬仔_tidb (Ti D Ber I Ruk U8 Tg)]

谢谢你的回答
我目标集群是全新的空库。现在问题是导入这里报错，我不知道是不是后面还有其它表待导入而被这个报错中断了没继续导其它表？

[有猫万事足]

从流程上讲，其实对应数据的sst文件已经到了目标库上，才会做这个checksum。
即你的数据已经全部导入了，但是不正确。
例如，唯一索引可能对应2行数据。

可以说可能有其他表的数据问题没有查，但导入是已经全部做完了的。
所以前面checksum过了的，可以保证无错，所以我才会建议你单独尝试导入这个表的数据。

[有猫万事足]

@扬仔_tidb

total_kvs: 1053425055 vs 1053425056

怎么看都像是导入期间有人偷偷插了一条数据。

[扬仔_tidb (Ti D Ber I Ruk U8 Tg)]

tiup tidb-lightning-ctl --config lighting.toml --checkpoint-error-destroy=all

tiup is checking updates for component tidb-lightning-ctl …timeout(2s)!

The component tidb-lightning-ctl version is not installed; downloading from repository.

The component tidb-lightning-ctl not found (may be deleted from repository); skipped

Error: use tiup install tidb-lightning-ctl to install component tidb-lightning-ctl first: component not installed
tidb-lightning-ctl是怎么安装？

[有猫万事足]

ctl这个组件下面。

[Fly-bird]

tidb-lightning-ctl 直接再官网下载，是个集合包

[扬仔_tidb (Ti D Ber I Ruk U8 Tg)]

tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all
按官网案例这样操作后，再重新导入还是报相同错

[扬仔_tidb (Ti D Ber I Ruk U8 Tg)]

感谢楼上各位大佬的解答，问题目前已经定位和解决
原因：6版本里字符集导致大不写敏感和mysql保持一致，但是在5版本里却不敏感即jD和JD在5版本可以插入。
解决办法：把唯一索引关闭导入。导入完成后再把冲突行删除掉，只留大写。业务方确认过没问题。

[胡杨树旁]

增量模式，local 导入，但是设置了on-duplicate = “replace” 这个参数，导入的时候报错，[2023/12/04 14:29:40.914 +08:00] [ERROR] [main.go:103] [“tidb lightning encountered error stack info”] [error=“[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 16703975120714088230 vs 12785062943811019446) (total_kvs: 57132710 vs 57309744) (total_bytes:1267649449255 vs 1267662372737)”] [errorVerbose="[Lighting:Restore:ErrChecksumMismatch]checksum mismatched remote vs local => (checksum: 16703975120714088230 vs 12785062943811019446) (total_kvs: 57132710 vs 57309744) (total_bytes:1267649449255 vs 1267662372737)

[有猫万事足]

@胡杨树旁

remote vs local => (checksum: 16703975120714088230 vs 12785062943811019446) (total_kvs: 57132710 vs 57309744)

total_kvs：remote=57132710 vs local=57309744

还真有点像是插入的数据中有重复的主键或者唯一键。local就是你本地的，remote就是你库里的。
库里的少于本地的。

如果排除对应的表，在导入期间有人删除数据，那就重点查查主键或者唯一键冲突。

[胡杨树旁]

主键和唯一键冲突，这个应该怎么去排查，目标库是一个历史库，这张表只有一个主键id 查了下 distinct ID 的总数据量和 表的count(*) 是一样的，而且现在源端的数据已经清理了，没有办法查询源端的数据

[有猫万事足]

保险的办法当然是写个脚本，从导入的sql/csv之类的里面读出来和目标库对比一下。当然sst的话确实没有好的办法。

甚至前两类如果你有把握，不如直接使用逻辑导入。逻辑导入不会有后续的checksum。其实物理导入快归快，但是checksum+analyze一套检查下来，增量导入的情况下，不好说比逻辑导入快多少。

因为增量导入，物理模式的情况下，这个checksum会检查全表的checksum值。历史数据也会计算一遍。

[胡杨树旁]

这个脚本应该怎么写，一点思路都没有···········

[heiwandou (黑豌豆)]

写个脚本试一下

[有猫万事足]

虽然说出来感觉有点不靠谱，我还是想说，无论是一点思路没有，还是某个地方不知道怎么实现。都可以尝试先问问chatgpt。

描述清楚的话，起码能得到一个python的简易实现，调一调可能就能用了。最多是没有多线程之类的问题，性能没有办法保证。逻辑不太会出大错。

[胡杨树旁]

好主意，怎么就忘记问chatgpt了呢