【 TiDB 使用环境】生产环境
【 TiDB 版本】 5.2.2/7.5.3
源TiDB 5.2.2 ； 目标TiDB 7.5.3
已经使用 dumpling + lightning 完成了数据库的逻辑备份和导入恢复。
现在使用 tiup cdc:v5.2.2 创建同步任务进行增量数据同步到下游 7.5.3 集群
创建命令
tiup cdc:v5.2.2 cli changefeed create --pd=http://192.168.3.57:2379 --sink-uri="mysql://root:xxx@192.168.1.70:4001" --start-ts=xxxxxx --config=cdc.yml --changefeed-id=yyy
其中cdc.yml 内容如下
case-sensitive=false
[filter]
rules = ["xinyu.*", "social.*"]
[mounter]
worker-num = 16
然后CDC报错
"error": {
"addr": "192.168.3.132:8300",
"code": "CDC:ErrProcessorUnknown",
"message": "[CDC:ErrReachMaxTry]reach maximum try: 8: [CDC:ErrMySQLTxnError]Error 1406: Data too long for column 'content' at row 1: Error 1406: Data too long for column 'content' at row 1"
},
cdc的日志中错误信息如下
[2024/11/12 11:58:02.428 +08:00] [WARN] [mysql.go:931] ["execute DMLs with error, retry later"] [error="[CDC:ErrMySQLTxnError]Error 1406: Data too long for column 'content' at row 1: Error 1406: Data too long for column 'content' at row 1"] [errorVerbose="[CDC:ErrMySQLTxnError]Error 1406: Data too long for column 'content' at row 1: Error 1406: Data too long for column 'content' at row 1\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20210425183316-da1aaba5fb63/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByCause\n\tgithub.com/pingcap/errors@v0.11.5-0.20210425183316-da1aaba5fb63/normalize.go:282\ngithub.com/pingcap/ticdc/pkg/errors.WrapError\n\tgithub.com/pingcap/ticdc/pkg/errors/helper.go:30\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLWithMaxRetries.func1.3\n\tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:981\ngithub.com/pingcap/ticdc/cdc/sink.(*Statistics).RecordBatchExecution\n\tgithub.com/pingcap/ticdc/cdc/sink/statistics.go:112\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLWithMaxRetries.func1\n\tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:968\ngithub.com/pingcap/ticdc/pkg/retry.run\n\tgithub.com/pingcap/ticdc/pkg/retry/retry_with_opt.go:54\ngithub.com/pingcap/ticdc/pkg/retry.Do\n\tgithub.com/pingcap/ticdc/pkg/retry/retry_with_opt.go:32\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLWithMaxRetries\n\tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:960\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLs\n\tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:1121\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSinkWorker).run.func3\n\tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:816\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSinkWorker).run\n\tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:854\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).createSinkWorkers.func1\n\tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:657\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
问题1
从cdc的日志中怎么判断content报错是那个库的那个表呢？
问题2
确认源库和目标字符集一样，表字段的类型一模一样，为啥出现这个问题
问题3
手动把目标库中varchar的大小调整到 tidb要求的上线，remove任务之后，重新创建还是报错，问题出现在哪里呢？
破防了啊，这个字段还能不一样长。
666