tidb中不区分null 和’’ ，都是null

前期导入的时候没有报错

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

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

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

关闭checksum 的话是哪个参数控制的，我这边看下，看了下导出的数据和导入数据进行了一下对比，数据不一致

增量模式，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…

看下memory 有变化吗？如果没有变化的话应该是遇到了bug,需要重启对应的tidb节点

看数据量大小，数据量小的每日全备+增量备份 数据量大的定期全备+增量备份，有备无患

好的 大体理解了 谢谢

这些参数都是默认值，没有过修改，但是还不是很理解是以哪个为准还是说有内部的清理机制

ghtning 会生成一个checkpoint 文件 ，如果没有设置路径的话默认在/tmp下，一个已pb 结尾的文件，删除了重新启动试下

今天单独扩容的一个drainer,下游的checkpoint 表是新建的，没有同名的

另外起的一个drainer,下游的checkpoint 表也是新建的，没有同名的

stop 了，然后就很快

找到问题的原因了，之前这套集群升级过，但是升级失败了，有个tidb节点起不来，把那个节点stop 掉了，ddl恢复了

不知道为啥显示是空表

[image] 查看那了下 基本表里面都有数据，有的多有的少

好的 谢谢 tikv_gc_safe_point 这个参数的值是：20230922-20:58:49 +0800 是不是就代表20230922-20:58:49 +0800之后的数据版本都有保留，我都可以找回来