# TiCDC 的使用 - 灾难场景的最终一致性复制

__*TiCDC 最终一致性复制*__

![left](./student-guide/diagram/TiCDCDisasterRecovery_aa_001_20220622.png)

-------------------------------------------------------------
从 v5.3.0 版本开始,TiCDC 支持将上游 TiDB 的增量数据备份到下游集群的 S3 存储或 NFS 文件系统。当上游集群出现了灾难,完全无法使用时,TiCDC 可以将下游集群恢复到最近的一致状态,即提供灾备场景的最终一致性复制能力,确保应用可以快速切换到下游集群,避免数据库长时间不可用,提高业务连续性。

目前,TiCDC 支持将 TiDB 集群的增量数据复制到 TiDB 或兼容 MySQL 的数据库系统（包括 Aurora、MySQL 和 MariaDB）。当上游发生灾难时,如果 TiCDC 正常运行且上游 TiDB 集群没有出现数据复制延迟大幅度增加的情况,下游集群可以在 5 分钟之内恢复集群,并且最多丢失出现问题前 10 秒钟的数据,即 RTO <= 5 mins, P95 RPO <= 10s。

当上游 TiDB 集群出现以下情况时,会导致 TiCDC 延迟上升,进而影响 RPO:

TPS 短时间内大幅度上升
上游出现大事务或者长事务
Reload 或 Upgrade 上游 TiKV 集群或 TiCDC 集群
执行耗时很长的 DDL 语句,例如:add index
使用过于激进的 PD 调度策略,导致频繁 region leader 迁移或 region merge/split
使用前提

准备好具有高可用的 S3 存储或 NFS 系统,用于存储 TiCDC 的实时增量数据备份文件,在上游发生灾难情况下该文件存储可以访问。
TiCDC 对需要具备灾难场景最终一致性的 changefeed 开启该功能,开启方式是在 changefeed 配置文件中增加以下配置:

[consistent]
# 一致性级别,选项有:
# - none: 默认值,非灾难场景,只有在任务指定 finished-ts 情况下保证最终一致性。
# - eventual: 使用 redo log,提供上游灾难情况下的最终一致性。
level = "eventual"

# 单个 redo log 文件大小,单位 MiB,默认值 64,建议该值不超过 128。
max-log-size = 64

# 刷新或上传 redo log 至 S3 的间隔,单位毫秒,默认 1000,建议范围 500-2000。
flush-interval = 1000

# 存储 redo log 的形式,包括 nfs（NFS 目录）,S3（上传至S3）
storage = “s3://logbucket/test-changefeed?endpoint=http://$S3_ENDPOINT/"

灾难恢复

当上游发生灾难后,需要通过 cdc redo 命令在下游手动恢复。恢复流程如下:

确保 TiCDC 进程已经退出,防止在数据恢复过程中上游恢复服务,TiCDC 重新开始同步数据。
使用 cdc binary 进行数据恢复,具体命令如下:
cdc redo apply --tmp-dir="/tmp/cdc/redo/apply" \
    --storage="s3://logbucket/test-changefeed?endpoint=http://10.0.10.25:24927/" \
    --sink-uri=“mysql://normal:123456@10.0.10.55:3306/"
以上命令中:

tmp-dir :指定用于下载 TiCDC 增量数据备份文件的临时目录。
storage :指定存储 TiCDC 增量数据备份文件的地址,为 S3 或者 NFS 目录。
sink-uri :恢复数据到的下游地址。scheme 仅支持 mysql。