【已解决】TiCDC 创建任务的TSO 小于 gc_save_point

【概述】
1.把TiDB备份数据迁移到MySQL中;
2.TiDB备份使用 dumpling 工具,备份成功后存在 metadata 文件;
3.使用 metadata 文件中的 TSO 时间点作为ticdc 同步的 start-ts 参数值;
4.异常信息 :fail to create changefeed because start-ts 427709949750804538 is earlier than GC safepoint at 427720805776097280

【业务影响】
ticdc 同步任务无法创建
【TiDB 版本】
v4.0.12

麻烦发一下 集群的gc时间设置


您是不是想要看这些信息?

在发一下 dumpling的版本

v4.0.12

我这边使用的工具版本都与TiDB集群的版本一致的

如果 GC safepoint 小于 TiCDC changefeed 同步任务的开始时间戳 start-ts ,则用户可以直接在 cdc cli create changefeed 命令后加上 --disable-gc-check 参数创建 changefeed。

现在是 start-ts 要早于 GC safepoint ,不知道这里是不是您说的 ”GC safepoint 小于 TiCDC changefeed 同步任务的开始时间戳 start-ts“是否符合我当前的情况。
我当前的情况是这样的:举例说明:start-ts = 202109140909 而 GC safepoint = 202109151016
这两个时间点 的大小比较应该是 GC safepoint > start-ts

开启cdc --start-ts 要保证这个时间还没被gc掉。

1赞

看你们的数据是否能接受丢失,在 cdc cli create changefeed 命令后加上 --disable-gc-check 参数创建 changefeed,跳过检查可能出现数据丢失,如果需要保证数据不丢失, 需要重新dumpling出来,重新初始化目标端,保证导入后,创建任务的tso时间能晚于gc safepoint,可以设置gc的时间长一点来保证这一点。

对,现在的问题就是比较尴尬,我dumpling出来后,将备份的数据导入目标端后,gc safepoint 又已经刷新了

gc life time设置大一点

您好,这个参数我是不是可以直接在数据表中修改?

主要是现在导入目标端的时间非常的长,大约得需要十几个小时,所以这个问题搞得我一头雾水

设置时间超过你导入的时常 然后同步好在修改回去就可以

tikv-gc-life-time是个系统变量,set global修改

1赞

update mysql.tidb set VARIABLE_VALUE=“24h” where VARIABLE_NAME=“tikv_gc_life_time”;

感谢指导,我这就去try一下

感谢指导,我这就去操作一下

如果你的问题已经解决,请记得选择对你最有帮助的内容,选择对我有用。