dmctl check-task 卡住

Hacker_MMJa6UpY · 2022 年5 月 30 日 09:25

【 TiDB 使用环境`】测试环境
【 TiDB 版本】TiDB-v6.0.0 ; dmctl v6.0.0
【遇到的问题】
执行 tiup dmctl --master-addr 172.17.38.192:8261 check-task task_accounting_engines_pp.yaml 后一直卡住
【相关日志】

dm-master.log

[2022/05/30 05:19:17.298 -04:00] [INFO] [checker.go:477] [“exec query”] [unit=“task check”] [sql=“SHOW CREATE TABLE dm_meta.task_accounting_engines_pp_loader_checkpoint”]
[2022/05/30 05:19:17.298 -04:00] [INFO] [checker.go:477] [“exec query”] [unit=“task check”] [sql=“SHOW CREATE TABLE dm_meta.task_accounting_engines_pp_lightning_checkpoint_list”]
[2022/05/30 05:19:17.298 -04:00] [INFO] [checker.go:477] [“exec query”] [unit=“task check”] [sql=“SHOW CREATE TABLE dm_meta.task_accounting_engines_pp_syncer_checkpoint”]
[2022/05/30 05:19:17.299 -04:00] [INFO] [checker.go:275] ["
************ task task_accounting_engines_pp checking items ************
mysql_version
source db dump privilege checker
mysql_server_id
mysql_binlog_enable
mysql_binlog_format
mysql_binlog_row_image
source db replication privilege checker
online ddl checker
binlog_do_db/binlog_ignore_db check
table structure compatibility check
sharding table accounting_engines_pp.inner_account_ledger_log consistency checking
sharding table accounting_engines_pp.request_transaction_log consistency checking
sharding table accounting_engines_pp.user_account_ledger_log consistency checking
************ task task_accounting_engines_pp checking items ************"] [unit=“task check”]
[2022/05/30 05:19:17.299 -04:00] [INFO] [table_structure.go:348] [“start to check sharding tables”]
[2022/05/30 05:19:17.299 -04:00] [INFO] [table_structure.go:348] [“start to check sharding tables”]
[2022/05/30 05:19:17.299 -04:00] [INFO] [table_structure.go:348] [“start to check sharding tables”]
[2022/05/30 05:19:17.320 -04:00] [INFO] [table_structure.go:397] [“check sharding table structure over”] [“spend time”=21.582746ms]
[2022/05/30 05:19:17.321 -04:00] [INFO] [table_structure.go:397] [“check sharding table structure over”] [“spend time”=22.479725ms]
[2022/05/30 05:19:17.327 -04:00] [INFO] [table_structure.go:135] [“check table structure over”] [“spend time”=27.885711ms]

task 具体配置

name: task_accounting_engines_pp # 任务名称，需要全局唯一
task-mode: all # 任务模式，可设为 “full” - “只进行全量数据迁移”、“incremental” - “Binlog 实时同步”、“all” - “全量 + Binlog 实时同步”
shard-mode: “pessimistic” # 任务协调模式，可选的模式有 “”、"pessimistic、“optimistic”。默认值为 “” 即无需协调。如果是分库分表合并任务，请设置为悲观协调模式 “pessimistic”。
meta-schema: “dm_meta” # 下游储存 meta 信息的数据库
clean-dump-file: true # 是否清理 dump 阶段产生的文件，包括 metadata 文件、建库建表 SQL 文件以及数据导入 SQL 文件

target-database: # 下游数据库实例配置
host: “172.17.38.192”
port: 4000
user: “root”
password: “+lHNVEQEy339GqzXDWpTZ0DEIj6XJKLy/wwQFmfRF59Kvms=” # 推荐使用经 dmctl encrypt 加密后的密码

mysql-instances:
source-id: "mysql-01"           # 对应 source.toml 中的 `source-id`
route-rules: ["route-rule-1", "route-rule-2", "route-rule-3"]    # 该上游数据库实例匹配的表到下游数据库的 table routing 规则名称
#filter-rules: ["filter-rule-1"] # 该上游数据库实例匹配的表的 binlog event filter 规则名称
block-allow-list: "bw-rule-1"                 # 该上游数据库实例匹配的表的 block-allow-list 过滤规则名称，如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list
mydumper-config-name: "global"          # mydumpers 配置的名称
loader-config-name: "global"            # loaders 配置的名称
syncer-config-name: "global"            # syncers 配置的名称
routes: # 上游和下游表之间的路由 table routing 规则集
route-rule-1: # 配置名称
schema-pattern: “accounting_engines_pp” # 库名匹配规则，支持通配符 “" 和 “?”
table-pattern: "inner_account_ledger_log” # 表名匹配规则，支持通配符 “" 和 “?”
target-schema: “accounting_engines_pp” # 目标库名称
target-table: “inner_account_ledger_log” # 目标表名称
route-rule-2: # 配置名称
schema-pattern: “accounting_engines_pp” # 库名匹配规则，支持通配符 "” 和 “?”
table-pattern: “user_account_ledger_log*” # 表名匹配规则，支持通配符 “" 和 “?”
target-schema: “accounting_engines_pp” # 目标库名称
target-table: “user_account_ledger_log” # 目标表名称
route-rule-3: # 配置名称
schema-pattern: “accounting_engines_pp” # 库名匹配规则，支持通配符 "” 和 “?”
table-pattern: “request_transaction_log*” # 表名匹配规则，支持通配符 “*” 和 “?”
target-schema: “accounting_engines_pp” # 目标库名称
target-table: “request_transaction_log” # 目标表名称

block-allow-list: # 定义数据源迁移表的过滤规则，可以定义多个规则。如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list
bw-rule-1: # 规则名称
do-dbs: [“accounting_engines_pp”] # 迁移哪些库

mydumpers: # dump 处理单元的运行配置参数
global: # 配置名称
threads: 4 # dump 处理单元从上游数据库实例导出数据和 check-task 访问上游的线程数量，默认值为 4
chunk-filesize: 64 # dump 处理单元生成的数据文件大小，默认值为 64，单位为 MB
extra-args: “–consistency none” # dump 处理单元的其他参数，不需要在 extra-args 中配置 table-list，DM 会自动生成

loaders: # load 处理单元的运行配置参数
global: # 配置名称
pool-size: 8 # load 处理单元并发执行 dump 处理单元的 SQL 文件的线程数量，默认值为 16，当有多个实例同时向 TiDB 迁移数据时可根据负载情况适当调小该值
# 保存上游全量导出数据的目录。该配置项的默认值为 "./dumped_data"。
# 支持配置为本地文件系统路径，也支持配置为 Amazon S3 路径，如: s3://dm_bucket/dumped_data?region=us-west-2&endpoint=s3-website.us-east-2.amazonaws.com&access_key=s3accesskey&secret_access_key=s3secretkey&force_path_style=true
dir: "./dumped_data"

import-mode: "loader"
on-duplicate: "replace"
syncers: # sync 处理单元的运行配置参数
global: # 配置名称
worker-count: 4 # 应用已传输到本地的 binlog 的并发线程数量，默认值为 16。调整此参数不会影响上游拉取日志的并发，但会对下游产生显著压力。
batch: 100 # sync 迁移到下游数据库的一个事务批次 SQL 语句数，默认值为 100，建议一般不超过 500。
# 设置为 true，则将来自上游的 `INSERT` 改写为 `REPLACE`，将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`，保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。
safe-mode: true

buchuitoudegou · 2022 年6 月 1 日 02:32

check-task 对大批量表的检查确实会比较慢，不知道您同步的表数量有多少呢？另外，正如配置中注释说的那样，dumper 的 threads 直接影响 check-task 对表检查的并发数量，因此，这里建议您：

或许配置少量的表试一下是否还会卡住（这种情况下可能就不是 check-task 本身的问题）
增加 dumper 的 threads 数量（不要超过上游的 max_connections）

FYI: dmctl check-task卡住不动，没有错误信息

Hacker_MMJa6UpY · 2022 年6 月 9 日 03:41

我这边最后定位到问题是由于上游分表有一张的表结构（字段数据类型decimal精度）不一致导致，修复成一致后check执行很快通过了

sunzhaoyang · 2022 年6 月 9 日 03:51

赞~方便建个 issue 描述下精度不一致的字段，以及现象。方便我们后续修复吗？

https://github.com/pingcap/tiflow/issues

buchuitoudegou · 2022 年6 月 9 日 06:55

这个其实已经修复了（就算精度不一致，也不应该卡住，是一个 bug），在 6.1 版本应该没有这个问题了

system · 2022 年10 月 31 日 19:19

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。