diff --git a/ticdc/ticdc-changefeed-overview.md b/ticdc/ticdc-changefeed-overview.md index f93781f47916..53c8b953ef15 100644 --- a/ticdc/ticdc-changefeed-overview.md +++ b/ticdc/ticdc-changefeed-overview.md @@ -15,15 +15,16 @@ Changefeed 是 TiCDC 中的单个同步任务。Changefeed 将一个 TiDB 集群 以上状态流转图中的状态说明如下： -- Normal：同步任务正常进行，checkpoint-ts 正常推进。 +- Normal：同步任务正常进行，checkpoint-ts 正常推进。处于这个状态的 changefeed 会阻塞 GC 推进。 - Stopped：同步任务停止，由于用户手动暂停 (pause) changefeed。处于这个状态的 changefeed 会阻挡 GC 推进。 - Warning：同步任务报错，由于某些可恢复的错误导致同步无法继续进行。处于这个状态的 changefeed 会不断尝试继续推进，直到状态转为 Normal。最大重试时间为 30 分钟，超过该时间，changefeed 会进入 failed 状态。 处于这个状态的 changefeed 会阻挡 GC 推进。 - Finished：同步任务完成，同步任务进度已经达到预设的 TargetTs。处于这个状态的 changefeed 不会阻挡 GC 推进。 - Failed：同步任务失败。处于这个状态的 changefeed 不会自动尝试恢复。为了让用户有足够的时间处理故障，处于这个状态的 changefeed 会阻塞 GC 推进，阻塞时长为 `gc-ttl` 所设置的值，其默认值为 24 小时。在此期间，如果导致任务失败的问题被修复，用户可以手动恢复 changefeed。超过了 `gc-ttl` 时长后，如果 changefeed 仍然处于 Failed 状态，则同步任务无法恢复。 > **注意：** -> -> 如果 changefeed 遭遇错误码为 ErrGCTTLExceeded, ErrSnapshotLostByGC 或者 ErrStartTsBeforeGC 类型的错误，则不再阻塞 GC 推进。 +> +> - 如果是因为 changefeed 阻塞了 GC, 则 changefeed 最多阻塞 GC 推进 `gc-ttl` 所指定的时长，超过该时长后，changefeed 会被设置成 `failed` 状态，错误类型为 `ErrGCTTLExceeded`，不再阻塞 GC 推进。 +> - 如果 changefeed 遭遇错误码为 `ErrGCTTLExceeded`、`ErrSnapshotLostByGC` 或者 `ErrStartTsBeforeGC` 类型的错误，则不再阻塞 GC 推进。 以上状态流转图中的编号说明如下： diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 238c7039bbdf..ac5d6a6170c7 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -62,7 +62,7 @@ cdc cli changefeed list --server=http://127.0.0.1:8300 启动 TiCDC server 时可以通过 `gc-ttl` 指定 GC safepoint 的 TTL，也可以[通过 TiUP 修改](/ticdc/deploy-ticdc.md#使用-tiup-变更-ticdc-集群配置) TiCDC 的 `gc-ttl`，默认值为 24 小时。在 TiCDC 中这个值有如下两重含义： - 当 TiCDC 服务全部停止后，由 TiCDC 在 PD 所设置的 GC safepoint 保存的最长时间。 -- TiCDC 中某个同步任务中断或者被手动停止时所能停滞的最长时间，若同步任务停滞时间超过 `gc-ttl` 所设置的值，那么该同步任务就会进入 `failed` 状态，无法被恢复，并且不会继续影响 GC safepoint 的推进。 +- 当 TiCDC 的 GC safepoint 阻塞 TiKV GC 数据时，`gc-ttl` 表示 TiCDC 同步任务的最大同步延迟，若同步任务延迟超过 `gc-ttl` 所设置的值，那么该同步任务就会进入 `failed` 状态，并报 `ErrGCTTLExceeded` 错误，无法被恢复，不再阻塞 GC safepoint 推进。 以上第二种行为是在 TiCDC v4.0.13 版本及之后版本中新增的。目的是为了防止 TiCDC 中某个同步任务停滞时间过长，导致上游 TiKV 集群的 GC safepoint 长时间不推进，保留的旧数据版本过多，进而影响上游集群性能。 @@ -76,7 +76,13 @@ TiCDC 服务启动后，如果有任务开始同步，TiCDC owner 会根据所 如果该同步任务停滞的时间超过了 `gc-ttl` 指定的时长，那么该同步任务就会进入 `failed` 状态，并且无法被恢复，PD 对应的 service GC safepoint 就会继续推进。 -TiCDC 为 service GC safepoint 设置的存活有效期为 24 小时，即 TiCDC 服务中断 24 小时内恢复能保证数据不因 GC 而丢失。 +TiCDC 为 service GC safepoint 设置的默认存活有效期为 24 小时，即 TiCDC 服务中断 24 小时内恢复能保证 TiCDC 继续同步所需的数据不因 GC 而丢失。 + +## Failed 同步任务失败后如何恢复？ + +1. 通过 `cdc cli changefeed query` 查询同步任务的错误信息，尽快修复错误。 +2. 调大 `gc-ttl` 的值，给修复错误留出时间，确保错误修复后不会因为同步延迟超过 `gc-ttl` 而导致同步任务进入 `failed` 状态。 +3. 在评估系统影响后，调大 TiDB 的 [tidb_gc_life_time](/system-variables.md#tidb_gc_life_time-从-v50-版本开始引入) 的值以阻止 GC、保留数据，确保错误修复后不会因为 GC 清理数据而导致同步任务进入 `failed` 状态。 ## 如何理解 TiCDC 时区和上下游数据库系统时区之间的关系？