源端大事务导致DM卡住，状态是Running ,延迟严重

🪐 TiDB 技术问题 备份&数据迁移
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
TiDB v5.4.0 ,重度依赖 DM 同步MySQL数据到TiDB，TiDB目前主要提供查询能力
DM v5.4.0
MySQL 5.7

【概述】 场景 + 问题概述

MySQL源端 批量数据初始化/数据清理，单条SQL insert/update 影响行数在 150w 条左右，
task Running 状态正常，存在比较严重延迟，长时间卡在此事务过不去

【备份和数据迁移策略逻辑】

【背景】 做过哪些操作
解析 syncerBinlog 卡住点位binlog,发现是大事务操作(初始化数据/数据清理 数据条数达到 150w 以上)

【现象】 业务和数据库现象
DM 同步 延迟验证，卡在大事务过不去。
两个task都遇到此问题，分别是 insert /delete ,源端MySQL执行单条SQL 影响行数在150w+

【问题】 当前遇到的问题
DM 遇到大事务卡住，造成严重延迟，排查性能瓶颈 及解决方案
详细信息见附件dm_analyze.zip (12.4 MB)

【业务影响】

【TiDB 版本】

【附件】

  • 相关日志、配置文件、Grafana 监控（https://metricstool.pingcap.com/)
  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息
  • TiDB-Overview 监控
  • 对应模块的 Grafana 监控（如有 BR、TiDB-binlog、TiCDC 等）
  • 对应模块日志（包含问题前后 1 小时日志）
2

您可以尝试 5.3 系列版本吗？我们正在修复 5.4.0 的这个问题

1 个赞
3

提交完成后才看到这个贴子，DM能降级么

4

是需要把dm config导出，然后重建DM v5.3.0集群,再导入config 这个操作流程吧

5

有俩种方式

  1. patch 5.3.0 的版本，见 https://docs.pingcap.com/zh/tidb/stable/tiup-component-dm-patch
    tiup mirror clone tidb-dm-530-linux-amd64 --os=linux --arch=amd64 --dm-master=v5.3.0 --dm-worker=v5.3.0
cd tidb-dm-530-linux-amd64
tiup dm patch <cluster_name> dm-master-v5.3.0-linux-amd64.tar.gz -R dm-master
tiup dm patch <cluster_name> dm-worker-v5.3.0-linux-amd64.tar.gz -R dm-worker
  2. 新建 v5.3.0 的集群，使用 config export 导出 5.4.0 集群的配置文件，销毁 v5.4.0 的集群，使用 config import 将配置文件导入 v5.3.0 的集群，见 https://docs.pingcap.com/zh/tidb/stable/dm-export-import-config
1 个赞
6

收到，感谢

7

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