除了一个会话内相同操作多次,基本上 conn id + job id 可以定位分段的唯一执行。
BTW: K8S 环境的 POD 日志,最好用其他手段持久化一下。
还有看一下,tidb.log 在 duplicate key 报错期间的上下日志。
日志不太全,还是得看一下两个 batch 语句 start a Non-transactional DML做为起始时间 ,最后一个 jobid 做为结束时间 。
admin show ddl jobs 的 truncate 时间 ,看一下各个时间 有没有交叉。
应该还是遗留数据的问题,从切分上看,没问题。batch.txt 这个子任务前后有没有别的错误。因为执行多次,可以检查一下,truncate 前是不是上一个任务是不是确认结束了。
[2023/02/23 11:57:16.391 +08:00] [INFO] [nontransactional.go:423] [“start a Non-transactional DML”] [conn=4581018440105527369] [job=“job id: 17031, estimated size: 5000, sql: INSERT INTO sbtest.sbtestbak SELECT…
能不能看一下 tidb.log ,关键字 nontransactional.go 类似这样的日志,有没有出现边界重复。
tidb.log 日志例举如下:
[2022/12/30 09:45:53.436 +08:00] [INFO] [nontransactional.go:423] [“start a Non-transactional DML”] [conn=3074535777447707195] [job=“job id: 1, estimated size: 1000, sql: INSERT INTO `test_order`.`test_order_target` SELEC…
看一下 {clustername}-tidb → query detail → Panic And Critial Error 监控期间的曲线,是否如下图有 critical 的上升?
[binlog]需要从新的 binlog 位点重新初始化。
下游清理数据后,用 start-task --remove-meta ./task.yaml 重新发起。
DB2 上就是一个只读操作, create view 不就行了。
chunk-size = 1000 调大,调整到 20万~ 50万,再试一下。
PRIMARY KEY ( c_w_id , c_d_id , c_id ) 组合主键现在的分段方式,导致 tidb 执行计划需要用全表扫描。
如果要提升速度,可以把 chunk-size = 1000 调大,mysql 会变慢,tidb 因为函数可下推速度较快,大概调整到 20万~ 50万,处于 mysql 和 tidb 两者的平衡点,整体速度会提升。