【 TiDB 使用环境】
本地测试
【概述】场景+问题概述
本地测试ticdc同步数据到kafka，测试成功后将电脑关机，今天开启电脑后发现ticdc报错日志。
【TiDB 版本】
v5.2.2
【附件】
请问这种情况应该如何处理？如果删除了任务重新创建，我能否消费历史变更记录？
请问这种情况应该如何处理？如果删除了任务重新创建，我能否消费历史变更记录？
1 个赞
上游数据库已经过了 gc 时间了，可以用命令查看下上游数据库的 gc 时间：
SELECT HIGH_PRIORITY variable_value FROM mysql.tidb WHERE variable_name='tikv_gc_safe_point';
现在即使删了任务重新创建，也无法消费历史记录了，因为那个时间点的数据变更记录已经没有。
1 个赞
那是否意味着我只要调大gc_ttl时间就能使历史记录保存更长时间？调大gc_ttl会不会导致内存占用过大而发生oom？
1 个赞
- 是的，调大 tikv_gc_life_time 可以保留更长时间的历史数据。
- 保留时间过久，会导致范围查询的性能下降（mvcc机制下，key保留的版本越多，扫描时遍历满足条件key的数量也会越多）
1 个赞
仅仅使范围查询受影响吗？如果大部分操作都是新增，很少有修改操作，是否可以忽略该影响？还有个问题是如果历史数据还在，ticdc 有办法做到增量恢复吗？比如说新建一个同步任务然后从指定时间点恢复？
有任何 DML 操作，建议 gc 保留时间都不要太久。gc 主要是用作快速恢复误删数据 flashback 和历史版本读取 tidb_snapshot，这两个场景不多的话，还是调小 gc 保留时间，性能优先。
ticdc 要恢复任务的话，gc saft time 是不能过的，如果过了这个时间点，就只能重新导出一份数据，并记录好这个时间点，然后在创建任务时，使用 --start-ts 指定这个时间。
重新导出一份数据指的是？
下游是数据库的话，如果 ticdc 任务中断了，过了 gc 保留时间，恢复不了，就需要把上游数据重新导入下游，然后指定导出数据时的时间节点，让 ticdc 从这个时间点开始同步。
那这样岂不是很矛盾吗？官方建议使用ticdc替代tidb binlog，但是ticdc的gc保留时间由不宜过长，那如果故障时间较长，除了重新导入数据有什么可以达到增量恢复的效果吗？
确实，目前没什么好的方案。我这边遇到中断然后过期，就只能重新准备下游数据，重新同步
我再去了解下 ticdc 这块有没有更好的解决办法，或者未来会不会有类似解决增量同步的方案。
好的，谢谢
你好，我还有一个问题想请教一下， tikv_gc_life_time 和 ticdc 配置中的 gc_ttl 这两个有啥区别？
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。