DM task runs on a specific table, but the TRUNCATE statement is always skipped, and no configuration method can be found

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: dm 任务跑某张表,但是turncate 的语句总是被跳过,找不到配置的方法

| username: kuuhaku

[Test Environment for TiDB]
[TiDB Version] DM tool v5.3
[Encountered Issue: Phenomenon and Impact]
After executing the TRUNCATE command in MySQL, there is no change on the TiDB side. Upon checking the DM logs, it was found that this DDL was skipped. Tried many configurations, but DM always skips the TRUNCATE command.
[Resource Configuration]

[Attachments: Screenshots/Logs/Monitoring]

| username: 有猫万事足 | Original post link

In the document, there is no node called do-schema-rule under filters. Could it be an issue with rule name recognition? Try modifying it according to the 5.3 documentation and see if it works?

| username: kuuhaku | Original post link

[quote=“有猫万事足, post:2, topic:1013721”]
[/quote]do-schema-rule is just a rule name, you can define it however you like. I changed it to match the documentation, but the truncate command is still being skipped.

| username: 有猫万事足 | Original post link

From the error location, your DM version is 5.3.0. Then there is a long comment above.

* sharding table - we limit one DDL event to only contain operations for the same table
* drop database / drop table / truncate table: we ignore these operations

It is possible that there is sharding table aggregation, so a single truncate table operation upstream does not execute, but requires all shard group tables to perform this DDL before the downstream truncates.

However, just looking at this task, it doesn’t seem to be a sharding table. Are there other tasks that are also synchronizing different upstream databases into the same downstream table?

A similar issue on GitHub.

Related discussion on the forum.

| username: kuuhaku | Original post link

Synchronize data for just one table.

| username: tidb菜鸟一只 | Original post link

dm does not support TRUNCATE TABLE.

| username: 有猫万事足 | Original post link

From what I’ve seen, this issue might not be fixed by 6.1.

If you just want to avoid errors during synchronization, you can try setting safe-mode to true under syncers.

syncers:                             # Configuration parameters for the sync processing unit
  global:                            # Configuration name
    worker-count: 16                 # Number of concurrent threads for applying binlog transferred to the local, default is 16. Adjusting this parameter will not affect the concurrency of upstream log fetching but will put significant pressure on downstream.
    batch: 100                       # Number of SQL statements in a transaction batch migrated to the downstream database, default is 100. It is generally recommended not to exceed 500.
    enable-ansi-quotes: true         # If `sql-mode: "ANSI_QUOTES"` is set in `session`, this option needs to be enabled.
    # If set to true, `INSERT` from upstream will be rewritten as `REPLACE`, and `UPDATE` will be rewritten as `DELETE` and `REPLACE`, ensuring that data can be repeatedly imported during migration under the condition that there is a primary key or unique index in the table structure.
    safe-mode: false

You can try setting safe-mode to true under syncers. TiDB Data Migration Configuration

This is a fallback solution. You can also try other people’s methods, but if nothing else works, use this trick.

| username: 大飞哥online | Original post link