【 TiDB 使用环境】生产\测试环境\ POC
"msg": "[code=10001:class=dm-master:scope=not-set:level=high], Message: database driver error, RawCause: dial tcp 193.169.203.101:29362: i/o timeout, Workaround: Please check the database connection and the database config in configuration file."
在其他节点用mysql登录下游数据库时是可以登录的；关闭gtid-mode
source.yaml
source-id: "mysql-01"
# DM-worker 是否使用全局事务标识符 (GTID) 拉取 binlog。使用前提是上游 MySQL 已开启 GTID 模式。若上游存在主从自动切换，则必须使用 GTID 模式。
enable-gtid: false
from:
host: "193.169.203.102" # 例如：172.16.10.81
user: "root"
password: "Root123..." # 支持但不推荐使用明文密码，建议使用 dmctl encrypt 对明文密码进行加密后使用
port: 3306
task.yaml
name: task-test # 任务名称，需要全局唯一。
task-mode: incremental # 任务模式，设为 "incremental" 即只进行增量数据迁移。
# 配置下游 TiDB 数据库实例访问信息
target-database: # 下游数据库实例配置。
host: "193.169.203.101" # 例如：127.0.0.1
port: 29362
user: "root"
password: "" # 推荐使用经过 dmctl 加密的密文。
# 使用黑白名单配置需要同步的表
block-allow-list: # 数据源数据库实例匹配的表的 block-allow-list 过滤规则集，如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
bw-rule-1: # 黑白名单配置项 ID。
do-dbs: ["bbigdata"] # 迁移哪些库。
# 配置数据源
mysql-instances:
- source-id: "mysql-01" # 数据源 ID，即 source1.yaml 中的 source-id
block-allow-list: "bw-rule-1" # 引入上面黑白名单配置。
# syncer-config-name: "global" # 引用下面的 syncers 增量数据配置。
meta: # task-mode 为 incremental 且下游数据库的 checkpoint 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在，则以 checkpoint 为准。
binlog-name: "mysql-bin.000022" # 第 1 步中记录的日志位置，当上游存在主从切换时，必须使用 gtid。
binlog-pos: 156
#binlog-gtid: "09bec856-ba95-11ea-850a-58f2b4af5188:1-9"
【复现路径】做过哪些操作出现的问题
相关日志、配置文件、Grafana 监控（https://metricstool.pingcap.com/ )
TiUP Cluster Display 信息
TiUP CLuster Edit config 信息
TiDB-Overview 监控
对应模块的 Grafana 监控（如有 BR、TiDB-binlog、TiCDC 等）
对应模块日志（包含问题前后 1 小时日志）
若提问为性能优化、故障排查 类问题，请下载脚本 运行。终端输出的打印结果，请务必全选 并复制粘贴上传。
当前DM cluster和TiDB等部署在同一集群，共享命名空间。
basic-tidb NodePort 10.99.92.86 4000:29362/TCP,10080:653/TCP 5d
能发一下下游数据库的配置吗？在 task.yaml 里
atidat:
"msg": "[code=10001:class=dm-master:scope=not-set:level=high], Message: database driver error, RawCause: dial tcp 193.169.203.101:29362: i/o timeout, Workaround: Please check the database connection and the database config in configuration file."
没有啊，看报错是尝试过对这个ip:port连接。
开始以为是密码没写，但看这个log，连接阶段就不通了
是的。追了下dm-master log，不知道是不是rpc问题
现在现象上看，有两个node有disk pressure，1个pd和1个tikv挂了
看下TiDB的集群状态，tiup cluster display。
atidat
2022 年4 月 13 日 07:34
13
mysql> select * from CLUSTER_INFO;http://basic-pd-2.basic-pd-peer.tidb-cluster.svc:2379/pd/api/v1/status ”: dial tcp: lookup basic-pd-2.basic-pd-peer.tidb-cluster.svc on 10.96.0.10:53: no such host
pd-2.loghttp://basic-pd-0.basic-pd-peer.tidb-cluster.svc:2379 0 } {http://basic-pd-1.basic-pd-peer.tidb-cluster.svc:2379 0 }]
atidat
2022 年4 月 13 日 07:39
14
check-task源码，感觉日志不够看的，定位不出来是哪的问题
func (s *Server) CheckTask(ctx context.Context, req *pb.CheckTaskRequest) (*pb.CheckTaskResponse, error) {
var (
resp2 *pb.CheckTaskResponse
err2 error
)
shouldRet := s.sharedLogic(ctx, req, &resp2, &err2)
if shouldRet {
return resp2, err2
}
_, _, err := s.generateSubTask(ctx, req.Task, req.ErrCnt, req.WarnCnt)
if err != nil {
// nolint:nilerr
return &pb.CheckTaskResponse{
Result: false,
Msg: err.Error(),
}, nil
}
return &pb.CheckTaskResponse{
Result: true,
Msg: "check pass!!!",
}, nil
}
要看源码的话，在 checker 目录下。不过看 log 不像是那里的问题…这时候需要有大佬来看看。。
我遇到了一样的问题，target-host 的host设置了slb地址，提示： “msg”: “[code=10001:class=dm-master:scope=not-set:level=high], Message: database driver error, RawCause: dial tcp 10.0.111.10:4000: i/o timeout, Workaround: Please check the database connection and the database config in configuration file.”,
应该不是一个问题。
SLB 地址是可以用的，只要保证 DM 运行的机器能用 mysql 客户端连上这个地址背后的 TiDB（TiDB Cloud 暴露的也是类似的地址）。
