【 TiDB 使用环境】生产环境Poc
【 TiDB 版本】4.0.13，6.1.7，MySQL版本5.7.21，dm版本2.0.3
需求：MySQL集群迁移至tidb集群，尝试了迁移至6.1.7后报错，后面又试了4.0.13，都是报错，都是在全量备份的时候报错，可能跟tidb集群版本没关系。
同步用户的权限如下
grant SELECT,RELOAD,LOCK TABLES,REPLICATION SLAVE,REPLICATION CLIENT on *.*
grant SELECT,INSERT,CREATE,LOCK TABLES ON db_name.*
source配置如下
cat dm-source-oltp-137-db58_zzlogistics.yaml
source-id: "source-xxxx-xxxx" # 数据源的名
# DM-worker 是否使用全局事务标识符 (GTID) 拉取 binlog。使用前提是在上游 MySQL 已开启 GTID 模式。
enable-gtid: false
from:
host: "xxxx" # 上游数据源ip等相关信息
user: "xxxx"
password: "xxxx"
port: xxxx
task配置文件如下
# 任务名，多个同时运行的任务不能重名。
name: "task-xxxx-xxxx"
#shard-mode: "pessimistic" #分库分表合并需要设置为悲观模式
# 全量+增量 (all) 迁移模式。
task-mode: "all"
# 下游 TiDB 配置信息。
target-database:
host: "xxxx"
port: xxxx
user: "xxxx"
password: "xxxx"
# 当前数据迁移任务需要的全部上游 MySQL 实例配置。
mysql-instances:
-
# 上游实例或者复制组 ID，参考。
source-id: "source-xxxx-xxxx"
# 需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `block-allow-list` 的配置。
block-allow-list: "global" # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
# dump 处理单元的配置项名称，用于引用全局的 dump 处理单元配置。
mydumper-config-name: "global"
loader-config-name: "global"
syncer-config-name: "global"
filter-rules: ["filter-rule-1"]
route-rules: ["route-rule-1"] # 数据源表迁移到目标 TiDB 表的路由规则，可以定义多个规则
# 黑白名单全局配置，各实例通过配置项名引用。
block-allow-list: # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
global:
do-tables:
- db-name: "xxxx"
tbl-name: "*"
filters: # 定义过滤数据源特定操作的规则，可以定义多个规则
filter-rule-1: # 规则名称
schema-pattern: "xxxx" # 匹配数据源的库名，支持通配符 "*" 和 "?"
table-pattern: "*" # 匹配数据源的表名，支持通配符 "*" 和 "?"
events: ["tuncate table","drop table"] # 匹配上 schema-pattern 和 table-pattern 的库或者表的操作类型
action: Ignore # 迁移（Do）还是忽略(Ignore)
routes: # 定义数据源表迁移到目标 TiDB 表的路由规则，可以定义多个规则
route-rule-1: # 规则名称
schema-pattern: "xxxx" # 匹配数据源的库名，支持通配符 "*" 和 "?"
target-schema: "xxxx" # 目标 TiDB 库名
# dump 处理单元全局配置，各实例通过配置项名引用。
mydumpers:
global:
threads: 8 # dump 处理单元从上游数据库实例导出数据的线程数量，默认值为 4
chunk-filesize: 64 # dump 处理单元生成的数据文件大小，默认值为 64，单位为 MB
extra-args: "-B xxxx" # dump 处理单元的其他参数，从 DM 1.0.2 版本开始，DM 会自动生成 table-list 配置，在其之前的版本仍然需要人工配置。
loaders:
global:
pool-size: 2
syncers:
global:
worker-count: 32
batch: 100
问题描述，使用dm 2.0.3版本工具进行数据迁移，全量备份阶段，任务状态提示如下报错
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"sourceStatus": {
"source": "source-xxxx-xxxx",
"worker": "dm-xx.xx.xx.xx-xxxx",
"result": null,
"relayStatus": null
},
"subTaskStatus": [
{
"name": "task-xxxx-xxxx",
"stage": "Paused",
"unit": "Dump",
"result": {
"isCanceled": false,
"errors": [
{
"ErrCode": 32001,
"ErrClass": "dump-unit",
"ErrScope": "internal",
"ErrLevel": "high",
"Message": "mydumper/dumpling runs with error, with output (may empty): ",
"RawCause": "sql: SELECT COLUMN_NAME,EXTRA FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA=? AND TABLE_NAME=? ORDER BY ORDINAL_POSITION;: driver: bad connection",
"Workaround": ""
}
],
"detail": null
},
"unresolvedDDLLockID": "",
"dump": {
}
}
]
}
]
}
根据官方文档的指导重启任务没法解决问题，重启任务后又会重新做全量备份，循环报错。dm-worker.log日志报错如下，可以看到执行了近四个小时然后报错的。
[2024/04/11 18:12:09.125 +08:00] [ERROR] [dumpling.go:138] ["dump data exits with error"] [task=task-xxxx-xxxx] [unit=dump] ["cost time"=3h55m25.147905887s] [error="ErrCode:32001 ErrClass:\"dump-unit\" ErrScope:\"internal\" ErrLevel:\"high\" Message:\"mydumper/dumpling runs with error, with output (may empty): \" RawCause:\"sql: SELECT COLUMN_NAME,EXTRA FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA=? AND TABLE_NAME=? ORDER BY ORDINAL_POSITION;: driver: bad connection\" "]
[2024/04/11 18:12:09.125 +08:00] [INFO] [subtask.go:289] ["unit process returned"] [subtask=task-xxxx-xxxx] [unit=Dump] [stage=Paused] [status={}]
[2024/04/11 18:12:09.125 +08:00] [ERROR] [subtask.go:308] ["unit process error"] [subtask=task-xxxx-xxxx] [unit=Dump] ["error information"="{\"ErrCode\":32001,\"ErrClass\":\"dump-unit\",\"ErrScope\":\"internal\",\"ErrLevel\":\"high\",\"Message\":\"mydumper/dumpling runs with error, with output (may empty): \",\"RawCause\":\"sql: SELECT COLUMN_NAME,EXTRA FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA=? AND TABLE_NAME=? ORDER BY ORDINAL_POSITION;: driver: bad connection\"}"]
已经排查确认过，MySQL端没有流量访问，不存在有任务去kill连接，且没有类似pt-kill这种工具的任务执行。
后面网友建议升级dm集群版本，升级到6.1.7版本后报错依旧存在，报错虽然不一样，但是也类似
"errors": [
{
"ErrCode": 32001,
"ErrClass": "dump-unit",
"ErrScope": "internal",
"ErrLevel": "high",
"Message": "mydumper/dumpling runs with error, with output (may empty): ",
"RawCause": "sql: SHOW COLUMNS FROM `db58_zzlogistics`.`logistics_base_0`: driver: bad connection",
"Workaround": ""
}
],
还试了在全量备份期间手动做了一个select sleep(100000000)，dm执行一个多小时后报错（备份文件也是1.3T左右，用2.0.3的时候并发数是2，用6.1.7的时候给了8，所以执行时间减少了差不多3/4），这也侧面反应，dm连接异常应该不是MySQL端kill的，而且过了很久之前测试的sleep这个查询都还在。
[2024/04/12 16:24:01.300 +08:00] [ERROR] [dumpling.go:152] ["dump data exits with error"] [task=task-xxxx-xxxx] [unit=dump] ["cost time"=1h5m36.89669174s] [error="ErrCode:32001 ErrClass:\"dump-unit\" ErrScope:\"internal\" ErrLevel:\"high\" Message:\"mydumper/dumpling runs with error, with output (may empty): \" RawCause:\"sql: SHOW COLUMNS FROM `d
xxxx`.`logistics_base_0`: driver: bad connection\" "]
[2024/04/12 16:24:01.300 +08:00] [INFO] [subtask.go:356] ["unit process returned"] [subtask=task-xxxx-xxxx] [unit=Dump] [stage=Paused] [status="{\"totalTables\":41,\"completedTables\":1,\"finishedBytes\":1314877011547,\"finishedRows\":413061038,\"estimateTotalRows\":350604900}"]
[2024/04/12 16:24:01.886 +08:00] [ERROR] [subtask.go:377] ["unit process error"] [subtask=task-xxxx-xxxx] [unit=Dump] ["error information"="ErrCode:32001 ErrClass:\"dump-unit\" ErrScope:\"internal\" ErrLevel:\"high\" Message:\"mydumper/dumpling runs with error, with output (may empty): \" RawCause:\"sql: SHOW COLUMNS FROM `db58_zzlogistics`.`logis
tics_base_0`: driver: bad connection\" "]
两次报错提示的SQL，用同步用户登录到MySQL是可以正常执行得到相应的结果，整个流程试过单个小表是没问题的，整库的话就有问题。