lightning导入报错checksum mismatched remote vs local

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

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：4.0.2
  • 【问题描述】：导入checksum不一致

[2020/07/08 17:33:57.223 +08:00] [ERROR] [restore.go:109] [-] [table=hz_ods_source.rn_worker_attendance_2019_08] [status=checksum] [error=“checksum mismatched remote vs local => (checksum: 13074461541046819684 vs 11253811792635397882) (total_kvs: 3315720 vs 4180788) (total_bytes:409877039 vs 507533019)”]
[2020/07/08 17:33:57.223 +08:00] [ERROR] [main.go:82] [“tidb lightning encountered error stack info”] [error=“restore table dim.dim_team_worker_df failed: checksum mismatched remote vs local => (checksum: 7653677028192941198 vs 12081930815224761565) (total_kvs: 2472118 vs 3100140) (total_bytes:833021059 vs 936397782)”] [errorVerbose=“checksum mismatched remote vs local => (checksum: 7653677028192941198 vs 12081930815224761565) (total_kvs: 2472118 vs 3100140) (total_bytes:833021059 vs 936397782)\ngithub.com/pingcap/tidb-lightning/lightning/restore.(*TableRestore).compareChecksum\ \t/home/jenkins/agent/workspace/build-linux-arm64-4.0/go/src/github.com/pingcap/tidb-lightning/lightning/restore/restore.go:1438\ngithub.com/pingcap/tidb-lightning/lightning/restore.(*TableRestore).postProcess\ \t/home/jenkins/agent/workspace/build-linux-arm64-4.0/go/src/github.com/pingcap/tidb-lightning/lightning/restore/restore.go:1118\ngithub.com/pingcap/tidb-lightning/lightning/restore.(*TableRestore).restoreTable\ \t/home/jenkins/agent/workspace/build-linux-arm64-4.0/go/src/github.com/pingcap/tidb-lightning/lightning/restore/restore.go:782\ngithub.com/pingcap/tidb-lightning/lightning/restore.(*RestoreController).restoreTables.func1\ \t/home/jenkins/agent/workspace/build-linux-arm64-4.0/go/src/github.com/pingcap/tidb-lightning/lightning/restore/restore.go:608\ runtime.goexit\ \t/usr/local/go/src/runtime/asm_arm64.s:1128\ restore table dim.dim_team_worker_df failed”]
[2020/07/08 17:33:57.224 +08:00] [ERROR] [main.go:83] [“tidb lightning encountered error”] [error=“restore table dim.dim_team_worker_df failed: checksum mismatched remote vs local => (checksum: 7653677028192941198 vs 12081930815224761565) (total_kvs: 2472118 vs 3100140) (total_bytes:833021059 vs 936397782)”]

如日志所示，这张表的前后数据不一致。清除断点重试后，仍旧如此。

2
  1. 这张表可能本身已有数据，影响最终结果。
  2. 如果目标数据库的校验和全是 0，表示没有发生任何导入，有可能是集群太忙无法接收任何数据。
  3. 如果数据源是由机器生成而不是从 Mydumper 备份的，需确保数据符合表的限制，例如：
  • 自增 (AUTO_INCREMENT) 的列需要为正数，不能为 0。
  • 唯一键和主键 (UNIQUE and PRIMARY KEYs) 不能有重复的值。
  1. 如果 TiDB Lightning 之前失败停机过，但没有正确重启，可能会因为数据不同步而出现校验和不一致。

按官方文档，我排除了1,2,3点原因的可能性。

3

https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-misuse-handling#解决方案

麻烦通过日志确认一下，断点信息是否被正确清理了

5 
tidb-lightning-ctl --checkpoint-error-destroy=all

这个是清除断点的操作么

6

请问之前导入的时候是报了什么错误 ？
如果是不可恢复的错误导致的退出的话，这个操作会清理断点信息，方便后续重新导入，如果这个表没有出错则无操作

7

同样的错误，校验值不一样。 我用tidb-lightning-ctl --checkpoint-error-destroy=all，再重启lighting，还是一样的错误。

8

只是 checksum 不一致的错误的话，通过 tidb-lightning-ctl --checkpoint-error-destroy=all 是不会清除断点信息的，需要手动清理一下

9

这文档上也没提，哈哈。那怎么手动清理啊。

10

如果 checkpoint 是 file 类型的，可以通过手动删除 file 文件方式清理断点信息
如果是 mysql 类型的，可以到下游的 checkpoint 库中，找到对应的表，删除表

11
  • -我手动删除了断点文件，还是报同样的错。
12

image
image799×161 17.5 KB

通过 --checkpoint-remove=all 清除断点文件可以吗