为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
TiDB: v5.0.1
TiCDC: v5.0.1
MySQL: 5.7.24-log MySQL Community Server (GPL)
【问题描述】
需求：使用 TiCDC 将上游 TiDB 所有历史数据全部同步到下游 MySQL ，并实时增量同步，即实现“全量+增量”效果。
由于 start-ts 不指定，会默认从系统当前时间开始同步，所以无法同步“历史数据”。但是要指定 start-ts ，我却不知道如何设置这个值。
查了官方文档，找到如下信息：
start-ts 为 0 ，跟不指定是同样的效果。tikv_gc_safe_point 这个参数值我也没查到。请问，我该如何找到正确的 TSO 值？
tikv_gc_safe_point 看来也不是变量。
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration
参考看下。
tidb 默认 gc 时间是 10m ，看样子之前应该没有改过，建议重新 dump 再进行 start ts 的指定
目前没有工具能直接获取一个合适的 ts 来同步所有的历史数据。
下面脚本可以抓取一个靠近 gc safepoint 的 ts 来同步 tidb 还没 gc 掉的历史数据
--start-ts=$(( $(pd-ctl -u http://0.0.0.0:2379 service-gc-safepoint | jq '.service_gc_safe_points[] | select(.service_id == "gc_worker") | .safe_point') + 1000 ))
注意：这种操作极易引发 TiKV 和 TiCDC oom，请勿在生产集群上使用。
可以试试使用 dumpling 的方式导出数据，使用 lightning 导入。dumpling 可以获取 tso 信息。再使用 TiCDC 同步增量。
好的 ，感谢。
请帮忙确认下，如下步骤是否正确：
start-ts 值为第一步中查到的 TSO 值。是的，另外需要注意是否有 TiDB 和 MySQL 不兼容的语法等。
感谢解答。
请问，我是不是对 TiCDC 理解有误？其实，我就是想实现 MySQL 作为 TiDB 的从库，这个工具不是做这个的吗？那，TiCDC 这个产品设计初衷是解决什么场景需求呢？
@MyronWang ticdc 只做增量部分，但是不建议做超过 200GB 以上的增量数据，后面我们会持续优化。
@overvenus ./cdc cli --pd=[xxxx] tso query 可以获取当前 tso，但是 -1 可以解决这个问题，这个是建议的方式
service-gc-safepoint gc_worker 的值并不完全是，这块比较复杂哈，如果要算 还没 gc 掉的历史数据，建议通过 sql 并再减去一定的时间。
import time
int(time.mktime(time.strptime ('2020-07-01 12:00:00','%Y-%m-%d %H:%M:%S'))) * (2**18) * (10**3)
我看了下介绍，lightning 是专门导入 TiDB 的工具，似乎不支持导入 MySQL。导入的配置文件中需要知道 pd 的地址，这个 MySQL 肯定没有。那只能用 mysql 的工具导入了。
感谢解答。
请问，是否是说，将 start-ts 设置为 -1 ，就可以实现“全量+增量”的同步？
还有，请问，如何将 TSO 时间转换为时间呢，比如“424790145115881473”代表的时间是多少？
惭愧，原来是数据库领域的专业术语
。受教了，我了解下，感谢感谢！
抱歉，之前文档里是有提到支持 MySQL ，可能因为兼容性问题又去掉了吧。那么建议使用 loader 来导入，可以先忽略提示使用lightning。
没事没事。
loader 这个工具的文档请问链接是啥，我学习下。
第一步获取全量备份时的 position 如下：
第二步按照 @yilong 建议的，使用 loader 将备份全量导入 MySQL；
第三步， 创建同步任务报错：
然后，我查看了下 GC safepoint，如下：
我备份数据时的 TSO 大概是上午12点，但是 GC safepoint 却是下午2点多，这必然会报此错。
如此说来，在执行全量备份后，主库不能有新数据写入，否则 GC safepoint 就会更新，那这显然不合理，主库不可能中断业务吧？
烦请帮忙解答，感谢！
