dump和lighting导出导入时间太久，导致ticdc失败

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

【 TiDB 使用环境】生产环境
【 TiDB 版本】
【遇到的问题：问题现象及影响】
由于新老集群版本跨度大，想在旧集群不升级的情况下进行部分数据迁移
第一步 用dumpling导出用了24小时
第二步 用lighting导入用了24小时
今天用ticdc 指定start-ts为7月17号，报

[CDC:ErrStartTsBeforeGC]fail to create changefeed because start-ts 442908153428574216 is earlier than GC safepoint at 442980806507102208

请问大神们，这种情况下怎么解？难道要在ticdc配置完成前把tidb集群的gc时间改很长比如3天?

2

大数据量迁移的话，建议直接把gc先关掉
SET GLOBAL tidb_gc_enable=FALSE;

3

是的，需要调整成一个较大的值，不然会失败。如果gc调大怕磁盘空间不够的话考虑用binlog做同步也是可以的。

1 个赞
4

如果你不想改gc 可以试试binlog同步数据，binlog存本地可以设置数据有效期

5

调大GC时间吧，默认10分钟肯定不行的

6
  1. 调整 TiCDC 同步的 start-ts：可以指定一个大于当前 GC safepoint 的时间戳作为 start-ts，确保不早于 GC safepoint。可以使用如下命令获取当前集群的 GC safepoint：
SELECT VARIABLE_NAME, VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_safe_point';

然后根据返回结果中的 VARIABLE_VALUE，调整 TiCDC 的 start-ts 为比这个值稍晚一些的时间戳。
2. 调整 TiDB 集群的 GC safepoint：如果迁移数据之后不再需要回滚到旧数据，可以考虑将 TiDB 集群的 GC safepoint 时间点后移。可以通过执行以下 SQL 语句将 GC safepoint 设置为较新的时间戳：

SET GLOBAL tikv_gc_safe_point = '<新的时间戳>';

注意，调整 GC safepoint 可能会对集群产生影响，请在进行操作前确保充分了解其影响，并做好备份和风险评估。
3. 使用 DM 工具：如果你的数据迁移涉及到不同版本的 TiDB 集群，你还可以考虑使用 TiDB Data Migration (DM) 工具。DM 可以帮助你在不同版本之间进行数据迁移，并在迁移过程中处理一些兼容性问题。通过 DM 工具进行数据迁移可以更加方便和灵活。

7

调大GC时间

8

多大数据量居然24小时，能不能研究下怎么减少导出导入时间

1 个赞
9

确实，先确认下是不是逻辑导出，再逻辑导入的。