【概述】
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掉。
看你们的数据是否能接受丢失，在 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修改
update mysql.tidb set VARIABLE_VALUE=“24h” where VARIABLE_NAME=“tikv_gc_life_time”;
感谢指导，我这就去try一下
感谢指导，我这就去操作一下
如果你的问题已经解决，请记得选择对你最有帮助的内容，选择对我有用。
