dm全量同步时如何微调下游tidb中的表结构,以便性能更好

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

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：v3.0.14
  • 【问题描述】：dm版本为v1.0.5

背景
使用task-mode: all模式时，dm会先拉取上游rds表的数据，之后拉取rds表的表结构信息，然后在下游tidb中创建表结构，最后开始灌入数据。

问题
当dm在下游tidb中创建表结构时，该如何微调部分表结构信息呢？
比如：上游rds中id是自增主键，下游tidb中改为唯一索引 ；上游rds中msg_id字段是唯一索引，下游tidb中改为普通索引 ；上游rds表为100G+大表，在下游tidb表结构中增加 SHARD_ROW_ID_BITS=4 以及 PRE_SPLIT_REGIONS=4 的定义 。
麻烦大佬帮确认一下，感谢

上游现有rds表结构
CREATE TABLE `test` (
  `id` bigint(20) unsigned NOT NULL auto_increment,
  `buyer_id` bigint(20) unsigned NOT NULL,
  `msg_id` varchar(60) NOT NULL,
  `action_type` int(11) NOT NULL,
  `coins` int(11) NOT NULL,
  `msg` varchar(30) NOT NULL,
  `create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  primary KEY(`id`),
  unique KEY `msg_id` (`msg_id`),
  KEY `buyer_id` (`buyer_id`),
  KEY `create_at` (`create_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;


期望下游tidb中的表结构为
CREATE TABLE `test` (
  `id` bigint(20) unsigned NOT NULL,
  `buyer_id` bigint(20) unsigned NOT NULL,
  `msg_id` varchar(60) NOT NULL,
  `action_type` int(11) NOT NULL,
  `coins` int(11) NOT NULL,
  `msg` varchar(30) NOT NULL,
  `create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  unique KEY uk_id(`id`),
  KEY `msg_id` (`msg_id`),
  KEY `buyer_id` (`buyer_id`),
  KEY `create_at` (`create_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 SHARD_ROW_ID_BITS=4 PRE_SPLIT_REGIONS=4;
2

你好，

将 tidb 中的表结构修改完毕后，在 task 文件中的 mydumper - extra-args 添加 --no-schema 试下。

3

好的 多谢 我试一下看看 如果可以就特别完美了

4

嗯，完成后希望得到反馈…

5

有点小问题
如果 Mydumper 使用 -m 参数，会导出不带表结构的数据，这时 loader 无法导入数据。
https://docs.pingcap.com/zh/tidb/v4.0/loader-overview#loader-使用文档

报错信息是

"msg": "[code=34012:class=load-unit:scope=internal:level=high] invalid data sql file, cannot find db - pt_buyer_vuqf_0009.buyer_gift_pack_148.sql\
github.com/pingcap/dm/pkg/terror.(*Error).Generate\
\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/pkg/terror/terror.go:232\
github.com/pingcap/dm/loader.(*Loader).prepareDataFiles\
\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/loader/loader.go:893\
github.com/pingcap/dm/loader.(*Loader).prepare\
\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/loader/loader.go:964\
github.com/pingcap/dm/loader.(*Loader).Restore\
\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/loader/loader.go:560\
github.com/pingcap/dm/loader.(*Loader).Process\
\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/loader/loader.go:488\
github.com/pingcap/dm/loader.(*Loader).Resume\
\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/loader/loader.go:678\
runtime.goexit\
\t/usr/local/go/src/runtime/asm_amd64.s:1357",

实际上库和该文件都是存在的 ，辛苦大佬帮看看解决方案

6

奇怪了 我试了一下方法居然生效且正常了

1： 在下游tidb中创建微调后的表结构

2： mydumper的配置使用默认即可，不要设置–no-schemas

3： 开启dm-worker同步任务后，全量同步+增量同步正常，任务状态没有异常，tidb中表结构为微调后的表结构

大佬帮确认下： 是dm看到下游已经存在了对应表结构，自己跳过了mydumper导出的表结构吗？

感谢

7

你好，

load 检查表名相同时，会忽略该表的表结构并正常执行 sql。

回归到这个报错，看下 query-status 完整信息，再看下 load 指定 mydumper 的路径是否正确

8

报错信息就是 （mydumper - extra-args 添加 --no-schemas后）query-status的错误信息，状态是pause 。

load 指定 mydumper 的路径是默认的，没修改过的。

load 检查表名相同时，会忽略该表的表结构并正常执行 sql。

如果是这样的话，那就可以不用设置mydumper中的no-schemas参数配置了。
9

这个和研发确认了一下，目前可以不加 --no-schema 来达到修改下游表结构的目的。

1 个赞
10

好的 ，辛苦大佬 谢谢 :stuck_out_tongue_closed_eyes:

11

:call_me_hand:

12

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