Lightning导入sql文件报错nil pointer dereference

[hey-hoho]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
测试环境

【概述】 场景 + 问题概述
dumpling导出mysql的单个库保存为sql文件形式，然后使用lightning导入到tidb中，导入报错。

panic: runtime error: invalid memory address or nil pointer dereference

从日志来看，表结构是已经全部导入成功的，现在猜测是哪张表的数据有问题导致失败，但是日志没有提示具体是哪张表，接下来该怎么排查呢？

详细日志和任务配置文件上传到附件中。
task-config.toml (1.9 KB) tidb-lightning.log (78.4 KB)

【TiDB 版本】
tidb v4.0.0
lightning toolkit-5.2.1

【附件】

• 相关日志、配置文件、Grafana 监控（https://metricstool.pingcap.com/)
• TiUP Cluster Display 信息
• TiUP CLuster Edit config 信息
• TiDB-Overview 监控
• 对应模块的 Grafana 监控（如有 BR、TiDB-binlog、TiCDC 等）
• 对应模块日志（包含问题前后 1 小时日志）

---

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[yilong (yi888long)]

麻烦tidb和lightning 使用相同版本试试，多谢。

[hey-hoho]

好的，我先都用4.0试试，但是奇怪的是我还有还几个库也是用同样的方式导入，都没有报错。

[hey-hoho]

刚尝试了用4.0.13的lightning去导入，发现还是报错，但是这次报错是说某个表不存在：

[2021/10/21 09:22:20.004 +08:00] [ERROR] [main.go:90] [“tidb lightning encountered error stack info”] [error=“table info xxxx.xxxx not found”] [errorVerbose=“table info xxx.xxxx not found
github.com/pingcap/br/pkg/lightning/restore.(*Controller).restoreTables
\tgithub.com/pingcap/br@/pkg/lightning/restore/restore.go:1176
github.com/pingcap/br/pkg/lightning/restore.(*Controller).Run
\tgithub.com/pingcap/br@/pkg/lightning/restore/restore.go:318
github.com/pingcap/br/pkg/lightning.(*Lightning).run
\tgithub.com/pingcap/br@/pkg/lightning/lightning.go:315
github.com/pingcap/br/pkg/lightning.(*Lightning).RunOnce
\tgithub.com/pingcap/br@/pkg/lightning/lightning.go:191
main.main.func2
\tgithub.com/pingcap/br@/cmd/tidb-lightning/main.go:86
main.main
\tgithub.com/pingcap/br@/cmd/tidb-lightning/main.go:87
runtime.main
\truntime/proc.go:203
runtime.goexit
\truntime/asm_amd64.s:1357”]
[2021/10/21 09:22:20.004 +08:00] [ERROR] [main.go:91] [“tidb lightning encountered error”] [error=“table info xxx.xxxx not found”]

但是我查了下tidb里面表结构已经导入进去了，sql文件中也确实存在这个表。

[yilong (yi888long)]

1. 这个感觉是大小写的问题，在4.0.0 好像无法识别到小写的。
   2 当前是测试环境还是正式环境？为什么选择了 4.0.0 版本？ 能否尝试使用较新的tidb版本？

[hey-hoho]

现在是生产环境，这个环境是4.0刚推出的时候部署的，想升级的话比较麻烦。
我也觉得是大小写问题，报not found的表名是全大写的，现在有没有什么方案能绕过这个问题呢

[hey-hoho]

好在这个库目前数据量不大，先用mysqldump重新导出了一份sql文件然后直接灌到tidb里面去了，暂时这样绕过吧