Sync_diff_inspector cannot recognize dm_task under DM 6.5

Translated
1

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

Original topic: sync_diff_inspector在DM 6.5下不能识别dm_task

| username: dba-kit

In DM 6.5, to support physical import, the value of import-mode has been changed from ['sql', 'loader'] to logical and physical. However, sync_diff_inspector has not been adapted, causing an error when retrieving task configuration from DM. The error message is: Message: invalid load mode 'logical', Workaround: Please choose a valid value in ['sql', 'loader'].

PS: Below is the new parameter description

    # The mode for data import during the full stage. It can be set to the following modes:
    # - "logical" (default). Uses TiDB Lightning logical import for importing. Documentation: https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-logical-import-mode
    # - "physical". Uses TiDB Lightning physical import for importing. Documentation: https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode
    #   Currently, "physical" is an experimental feature and is not recommended for production environments.
    import-mode: "logical"
2
| username: dba-kit | Original post link

However, looking at the source code, it directly calls the DM API to parse the task configuration. It is estimated that modifying the version number of github.com/pingcap/tiflow in go.mod will automatically fix it.

3
| username: baofengyu | Original post link

I also encountered this problem with DM version 6.5. When using sync_diff_inspector to validate the data, this error occurred. How did you solve it?

4
| username: dba-kit | Original post link

The master branch has been fixed. I compiled a binary version directly from the master branch and deployed it online. The tools in the new 6.5.2 version should also be fixed, so you can try using the binary files from there directly.

5
| username: dba-kit | Original post link

If upgrading the online version is too troublesome, there is a workaround: manually write the MySQL/TiDB access addresses for upstream and downstream, instead of obtaining them from DM.

6
| username: baofengyu | Original post link

Okay, thank you.

7
| username: baofengyu | Original post link

Okay, thank you.

8
| username: dba-kit | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.