按数据库维度tidb集群到TIDB集群迁移时遇到需要停止CDC问题问题

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

【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.3

现有两套TIDB集群，
Ti-A集群中有数据库 DB-1/DB-2/DB3
Ti-b集群中有数据库 DB-4/DB-5/DB6/DB-7

需要根据业务重要程度调整TIDB集群，

新增了两套TIDB集群
NewTi-A 和 NewTi-B ，但是目前需要把

Ti-A集群中的DB-1/DB-2 和 Ti-b集群中 DB6/DB-7 迁移到 NewTi-A集群中
Ti-A集群中的DB-3 和 Ti-b集群中 DB4/DB-5 迁移到 NewTi-B集群中

所以实际是按照数据库维度迁移的。 先迁移了 Ti-A集群中 DB-1 到了 NewTi-A集群中 DB-1，但是DB-1 有cdc同步数据到kafka的需求，迁移完成 DB-1 之后，cdc已经正常运行中。

目前按照备份完毕DB-2，准备进行restore恢复到 NewTi-A集群中的时候报错，提示error="failed to check task exists: found CDC changefeed(s) ... ... please stop changefeed(s) before restore"

详细日志参考如下

[2025/05/27 18:21:46.518 +08:00] [ERROR] [restore.go:64] ["failed to restore"] [error="failed to check task exists: found CDC changefeed(s): cluster/namespace: default/default changefeed(s): [tidb-primary-db1], please stop changefeed(s) before restore"] [errorVerbose="found CDC changefeed(s): cluster/namespace: default/default changefeed(s): [tidb-primary-db1], please stop changefeed(s) before restore\ngithub.com/pingcap/tidb/br/pkg/task.checkTaskExists\n\t/workspace/source/tidb/br/pkg/task/stream.go:1128\ngithub.com/pingcap/tidb/br/pkg/task.RunRestore\n\t/workspace/source/tidb/br/pkg/task/restore.go:604\nmain.runRestoreCommand\n\t/workspace/source/tidb/br/cmd/br/restore.go:63\nmain.newDBRestoreCommand.func1\n\t/workspace/source/tidb/br/cmd/br/restore.go:183\ngithub.com/spf13/cobra.(*Command).execute\n\t/root/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:940\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/root/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:1068\ngithub.com/spf13/cobra.(*Command).Execute\n\t/root/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:992\nmain.main\n\t/workspace/source/tidb/br/cmd/br/main.go:58\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1650\nfailed to check task exists"] [stack="main.runRestoreCommand\n\t/workspace/source/tidb/br/cmd/br/restore.go:64\nmain.newDBRestoreCommand.func1\n\t/workspace/source/tidb/br/cmd/br/restore.go:183\ngithub.com/spf13/cobra.(*Command).execute\n\t/root/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:940\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/root/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:1068\ngithub.com/spf13/cobra.(*Command).Execute\n\t/root/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:992\nmain.main\n\t/workspace/source/tidb/br/cmd/br/main.go:58\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267"]

[2025/05/27 18:21:46.518 +08:00] [ERROR] [main.go:60] ["br failed"] [error="failed to check task exists: found CDC changefeed(s): cluster/namespace: default/default changefeed(s): [tidb-primary-db1], please stop changefeed(s) before restore"] [errorVerbose="found CDC changefeed(s): cluster/namespace: default/default changefeed(s): [tidb-primary-db1], please stop changefeed(s) before restore\ngithub.com/pingcap/tidb/br/pkg/task.checkTaskExists\n\t/workspace/source/tidb/br/pkg/task/stream.go:1128\ngithub.com/pingcap/tidb/br/pkg/task.RunRestore\n\t/workspace/source/tidb/br/pkg/task/restore.go:604\nmain.runRestoreCommand\n\t/workspace/source/tidb/br/cmd/br/restore.go:63\nmain.newDBRestoreCommand.func1\n\t/workspace/source/tidb/br/cmd/br/restore.go:183\ngithub.com/spf13/cobra.(*Command).execute\n\t/root/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:940\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/root/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:1068\ngithub.com/spf13/cobra.(*Command).Execute\n\t/root/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:992\nmain.main\n\t/workspace/source/tidb/br/cmd/br/main.go:58\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1650\nfailed to check task exists"] [stack="main.main\n\t/workspace/source/tidb/br/cmd/br/main.go:60\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267"]

cdc 同步数据到Kafka是生产业务需要。 目前不能停止呢，

大佬们有没有其他解决方案和建议啊？

2

不能停机维护么？ 停掉维护好了在上线，不就ok了

1 个赞
3

把DB-1 快照恢复到NewTi-A以后，原有老集群的ticdc changefeed不要动，在老集群的ticdc开一个新的chengefeed，根据快照的时间，把老库的db-1数据写到下游的NewTi-A里面去。

其他库也这么处理，4个集群同步没问题了，再把业务流量切到NewTi-A，NewTi-B上去，同时关掉老集群的所有changefeed，在新集群上起changefeed写kafka。

这和主从切流量差不多的道理。

4

生产业务，不能停机维护的

5

没有考虑这个tidb 到tidb迁移会有这个限制，历史从MySQL迁移tidb的时候， 使用的dumpling + lightning 没有这个问题。

你说这个方案是 所有库保持迁移和数据同步和不切割业务及cdc.

目前是已经完成了一个库的完整切割。 迁移第二个库的时候遇到问题了。

6

再新建一个集群 NewTi-C， NewTi-A集群 再起一个 changefeed 把数据同步给 NewTi-C，把 2 6 7 迁移至 NewTi-C ，再把写kafka 的 changefeed 在 NewTi-C 启动，这个方案可以满足吗？

7

方案可行。就是过程中需要冗余一套生产TIDB集群，资源和费用的问题。

另外可能就是把刚才完成迁移的DB1再给回迁到原来的 Ti-A集群（Ti-A集群中已经删除 DB1），然后按照有猫的方案。

两种方案，一个是新增一套TIDB，一种是回迁业务再重迁移

8

你现在的问题是ticdc在NewTi-A不能起changefeed么。
那就不要起，你现在新老集群之间搞个主从复制，通过ticdc让两边数据一致，库的同步没问题了，再改kafka的changefeed到新集群NewTi-A不就好了。

你用这个方案的话，增量怎么搞呢？新集群和老集群数据都不同步，业务流量怎么切啊。

9

是NewTi-A 已经迁移过去一个DB1 库了，DB1上已经配置了cdc同步到kafka 然后同步另外一个数据库到NewTi-A的时候报错提示 NewTi-A库上不能有 cdc任务。 这个NewTi-A上已经存在的cdc是生产再用的，不能停止

1 个赞
10

这个是MySQL到TIDB， 应该是 dumpling + lightning + dm ， 其中dm做增量来着。

我看官方文档中 tidb 到tidb的迁移 推荐的是 br backup + restore + cdc 增量，没有推荐用 dumpling + lightning + dm

1 个赞
11

目前貌似只能新增集群的方案了，回迁的话，旧的集群中本身也有很多cdc任务的。那也不满足restore的方案

1 个赞
12

整的老复杂了，光看就觉得很痛苦了 :rofl:

13

开发要1拆2，运维只能配合了 :joy:

14

BR 是物理备份，恢复的时候有要求的

dumpling 是逻辑备份，数据量大的时候不太友好，导出慢
但是通过 lightning 写入还是可以的，逻辑的更方便控制

加油～

15

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