dm支持只做增量迁移怎么配置?

dm的task-mode支持incremental,就是说可以只做增量同步吧?

查看MySQL的binlog信息

MySQL [(none)]> show master status \G
*************************** 1. row ***************************
             File: mysql-bin.002763
         Position: 191
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: ec845e26-2e4d-11eb-9b77-fa163e73535a:1-1281
1 row in set (0.00 sec)

目前我这边按照如下的配置启动task,
task.yaml如下:

# 任务名,多个同时运行的任务不能重名。
name: "mysql-migrate-test-incremental"
# 全量+增量 (all) 迁移模式,full为全量。
task-mode: "incremental"
# 下游 TiDB 配置信息。
target-database:
  host: "tidb-e293bwk13f-tidb.tidb-e293bwk13f-xxxx.com"
  port: 4000
  user: "zgctest"
  password: "Testtest1"

# 当前数据迁移任务需要的全部上游 MySQL 实例配置。
mysql-instances:
-
  # 上游实例或者复制组 ID,参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。
  source-id: "mysql-metadb-01"
  # 需要迁移的库名或表名的黑白名单的配置项名称,用于引用全局的黑白名单配置,全局配置见下面的 `block-allow-list` 的配置。
  block-allow-list: "instance"          # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
  # dump 处理单元的配置项名称,用于引用全局的 dump 处理单元配置。
  # mydumper-config-name: "global"
  #
  # 增量时用syncers?
  syncer-config-name: "global"
  meta:       # `task-mode` 为 `incremental` 且下游数据库的 `checkpoint` 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在,则以 `checkpoint` 为准
    binlog-name: mysql-bin.002763
    binlog-pos:  191 
    binlog-gtid: "ec845e26-2e4d-11eb-9b77-fa163e73535a:1-1281"  # 对于 source 中指定了 `enable-gtid: true` 的增量任务,需要指定该值

# 黑白名单全局配置,各实例通过配置项名引用。
block-allow-list:                     # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
  instance:
    do-dbs: ["test"]                        # 需要迁移的上游表的白名单。

# dump 处理单元全局配置,各实例通过配置项名引用。
#mydumpers:
#  global:
#    rows: 32000
#    threads: 32

syncers:
  global:
    worker-count: 16
    batch: 100
    safe-mode: true 

通过query-status sub-task

报错如下:

ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

查了下网上的说法,但是我这边的Mysql没有做以下操作,

1.在主库上手动执行清除二进制日志文件

2.主库重启,重新同步时

请问只做增量同步, 是哪里配置的不对吗?感觉meta这块,我配置的不对,麻烦解答下哈,谢谢!

确认了下binlog文件都在。

dm 版本是多少

这个报错的含义与 mysql 相同,都是 gtid 点被 purged 了,可以在 mysql 中 show master status 检查下

只做增量迁移指的是下游 tidb 没有 mysql 存量数据?

dm的版本是v2.0.0,看了下mysql的git-purged,1-1237了,这个就会导致,dm里设置的gtid1-1281提示前面一部分找不到吗?这里reset 下是不是就可以了?

只做增量数据迁移是指:
下游的tidb有mysql的历史数据,我这边想前期通过lightning做一些历史数据的导入,然后进行业务的验证和压测,通过后在利用dm增量同步数据,

看了下,下游的tidb有个dm_meta库,清理相应的表,增量数据迁移就可以了,尴尬了:joy:

上游不要轻易 reset

dm meta 里面保存之前的同步信息,没有明确需要清理需谨慎

嗯嗯,好的

嗯,基本的解决思路就是:

  • 检查 master 的 binlog 是否被 purge。
  • 检查 relay.meta 中记录的位点信息。
    • relay.meta 中记录空的 GTID 信息,DM-worker 进程在退出时、以及定时 (30s) 会把内存中的 GTID 信息保存到 relay.meta 中,在没有获取到上游 GTID 信息的情况下,把空的 GTID 信息保存到了 relay.meta 中。见案例 case-772
    • relay.meta 中记录的 binlog event 不完整触发 recover 流程后记录错误的 GTID 信息,该问题可能会在 1.0.2 之前的版本遇到,已在 1.0.2 版本修复。