dm分表合并的ddl问题

🛸 其他技术问题
1

DM V6.0进行分库分表合并时，有个问题如果不注意可能酿成大祸！

上游MySQL操作删除某个分表数据的时候，采用delete from t1; 可正常删除数据，下游TiDB中的数据也能正常删除。

如果使用truncate table t1; 下游数据库的合并表t 将被清空。

DM task配置：

任务名，多个同时运行的任务不能重名。

name: “mysql2tidb9”

任务模式，可设为

full：只进行全量数据迁移

incremental： binlog 实时同步

all： 全量 + binlog 迁移

task-mode: “all”

下游 TiDB 配置信息。

target-database:
host: “xxx.xxx.xxx.xxx” # 例如：172.16.10.83
port: 5000
user: “root”
password: “QscUi/ODDWBDALE6/wfvRkBl3XbPxIU=” # 支持但不推荐使用明文密码，建议使用 dmctl encrypt 对明文密码进行加密后使用

当前数据迁移任务需要的全部上游 MySQL 实例配置。

mysql-instances:

上游实例或者复制组 ID。

source-id: “mysql-57”

需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 block-allow-list 的配置。

route-rules: [“sale-route-rule”]
block-allow-list: “listA”

routes:
sale-route-rule:
schema-pattern: “test*”
table-pattern: “t*”
target-schema: “test”
target-table: “t”

黑白名单全局配置，各实例通过配置项名引用。

block-allow-list:
listA: # 名称
do-dbs: [“test1”,“test2”,“test3”] # 需要迁移的上游表的白名单。

初始化数据：
上游MySQL数据
image

通过DM同步到下游TiDB的数据
image

DELETE操作：

上游MySQL操作delete
image

通过DM同步到下游TiDB的数据
image

TRUNCATE操作：
上游MySQL操作TRUNCATE
image

通过DM同步到下游TiDB的数据
image

2

emmm，看这个图不太明白呀。从时间上看，下游表在 14:57:23 就已经是空表了，而 truncate 语句在 14:57:31 才执行（不知道这个时间是不是对齐的）。怎么确定是 truncate 语句造成的呢？

现在 DM 的 syncer 应该是不会迁移 truncate 语句的：https://docs.pingcap.com/zh/tidb/stable/feature-shard-merge-pessimistic

3

你是官方的同学吗？

1、delete上游的一个分表，下游的合并表并没有清空（我截图截多了两行一点点，应该是下面这张图）
14:57:23那个时间点，是上一个命令（select count(*) from test.t;）执行完毕之后返回到客户端的时间，我忘记敲个回车显示当前时间了
image

2、谁说truncate不会迁移，你自己试试就知道了，而且我上面截图已经很清晰的说明truncate在下游TiDB中被执行了

4

请问您有开启 shard-mode 吗？如果上面的任务配置是全的话，您可能没有开启 shard-mode。具体是：

shard-mode: "pessimistic"

可以参考一下我上面发的链接，DM 在对合库合表的迁移场景是不会迁移 truncate table 语句的。

5

效果如下：
image

---
name: test
task-mode: all
shard-mode: "pessimistic" 

target-database:
  host: "x.x.x.x"
  port: 4000
  user: "root"

mysql-instances:
  - source-id: "mysql2"
    loader-config-name: "global"
    # continuous-validator-config-name: "global"

loaders:
  global:
    pool-size: 16
    import-mode: "loader"