关于出现DDL异常后rollback checkpoint过久

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

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【概述】 场景 + 问题概述
因为业务场景需要，用户可以更改表单类型从而导致数据库字段类型变更

【备份和数据迁移策略逻辑】
全库迁移，约3W张表
【背景】 做过哪些操作
遇到修改字段类型的时候，删除原字段，新增字段（列数据会丢失，这个业务允许的）
【现象】 业务和数据库现象

【问题】 当前遇到的问题
每次遇到修改字段类型的时候，dm首先会rollback checkpoint 约10分钟，数据库syncer_checkpoint表约3000条数据
【业务影响】
导致每次遇到修改字段类型的时候，需要等待10分钟才告警，未能及时处理
【TiDB 版本】
TIDB:5.0 DM：2.0.2

1 个赞
2

与syncer_checkpoint有关系吗？能否可以通过清空syncer_checkpoint 来提升速度

3

我们在 2.0.4 版本优化了 rollback checkpoint 的速度 https://github.com/pingcap/dm/pull/1700

但是在同步报错时才会触发 rollback checkpoint，所以问题根源应该是 ddl 会引发报错。

清空 syncer_checkpoint 会丢失同步进度，不建议这么做。

4

如果仅保留cp_schema和cp_table为空的记录，是否可以？

5

其实有一个疑问，为啥要保留其他表的binlog信息？有什么作用吗？cp_schema和cp_table为空的记录不就已经是当前binlog的位置了吗？其

6

checkpoint 目前记录有全局和 table 级别的 checkpoint

  • 表级别的 checkpoint
    • 用于恢复在某些情况下断开，在全局 checkpoint 之后，会在表级别的 checkpoint 进行更细化的定位；
    • 重新在 binlog 事件里，找到表恢复的起始位置
  • 全局的 checkpoint
    • 用于重新接收 binlog 的起始位置

感兴趣的话可以看下 PU DM 的相关课程。https://university.pingcap.com

7

嗯 好的，感谢，那有小问题，我可以干掉表级别的checkpoint吗？或者有相关设置取消表级别的rollback checkpoint吗？ 因为业务经常改表，目前tidb5.1已经支持，但dm还不支持，所以经常触发rollback checkpoint，需要10分钟的时间，挺影响业务的。

8

生产环境业务经常改表 ？ 这个操作有点恐怖阿 :nerd_face:

还是保持稳定比较好

tidb 的 DDL 是无阻塞式的执行，肯定需要相应的检查和回滚模式来支持的，这个特性如此

解决问题的方式，还是在你自己手上了（例如mysql 执行 DDL 是阻塞式的，你肯定会选择无业务操作的时段）

9

确实有点恐怖，因为对接方的系统表单对应数据库中的表（30W张），只要表单变动了，对应的表也是会做改动的。
目前我们是以python脚本的方式，当DM异常暂停时，会去判断是否是修改表字段，然后以删除字段，再添加新字段的方式（列数据会丢失，但与对接方讨论后，可以接受）。
但有一点问题，就是我们需要即时同步对接方的数据库变动，因为我们这边需要做相对应的实时处理。
由于rollback checkpoint时间过长，有点苦恼，目前在开发和测试环境清理了表级别的checkpoint，rollback checkpoint速度提神飞快，但不知道有啥影响，
其实更多还是希望DM能尽早对其tidb5.1，这对我们将是一个相当重要的版本。

10

感觉这个可以在 task 配置中提前过滤掉这些 TiDB 不支持的修改字段的操作。https://docs.pingcap.com/zh/tidb-data-migration/stable/key-features#binlog-event-filter

只是这样上下游字段类型会不一致了。

11

由于 DM 是一张表一张表去回滚 checkpoint 的，当你删除了 checkpoint 记录之后,回滚速度的确会提升的。但是这样有可能会丢失数据，生产环境不推荐这样做

12

@GdCwh tidb_enable_change_column_type 这个环境变量在 TiDB v5.1中已经默认开启了

请问你说DM还需要对接 TiDB 5.1是什么意思呢？

13

目前本地已经升级为TIDB 5.1，通过sql语句可以修改字段类型，但使用dm 2.0.4 发现还是报错tidb_enable_change_column_type=false，tidb 已经确定开启。
考虑到dm也是有引入 tidb的校验，不知是否有更新？
github.com/pingcap/tidb v1.1.0-beta.0.20210330094614-60111e1c4b6f

14

感谢您提出的建议，之前其实我们也想过，只是这样对我们的业务影响较大，没有采纳。

15

但是如果一个用户的操作，导致rollback checkpoint时间有点长，影响到其他的用户，就有点得不偿失了。
能麻烦您说明一下，什么情况下会丢失数据吗？如果业务允许，暂时可能会这么做，待DM支持了再回到正常流程。

16

下游 checkpoint 是断点续传的位点，强烈不建议删除或者更改，如果位点丢失，就会导致重启时同步的位点有误。丢失数据或者数据重复写入都有可能啊。

你这边还是先提前过滤掉这类不支持的语句吧。然后去下游手动更改。

17

@GdCwh

感谢回复，明白你的需求啦
目前 DM 已经开始更进这方面了，PR 在这里 https://github.com/pingcap/dm/pull/1821

18

@GdCwh hi，这个 PR 已经被合并进去了，今晚的 nightly 版本应该就支持这个功能了，有空的话可以看一下是不是对你有帮助

19

好，非常感谢您的提醒

20

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