# `TiDB` Disaster Recovery Solution with `TiCDC`: Replication

![`smart`](TiCDCDisasterRecovery_aa_003_20220622.png)

-------------------------------------------------------------
`TiCDC` supports backing up incremental data from an upstream `TiDB` cluster to `S3` storage or an `NFS` file system of a downstream cluster. When the upstream cluster encounters a disaster and becomes unavailable, `TiCDC` can restore the downstream data to the recent eventually consistent state. This is the eventually consistent replication capability provided by `TiCDC`. With this capability, you can switch applications to the downstream cluster quickly, avoiding long-time downtime and improving service continuity.

Currently, `TiCDC` can replicate incremental data from a `TiDB` cluster to another `TiDB` cluster or a `MySQL-compatible` database system (including `Aurora`, `MySQL`, and `MariaDB`). In case the upstream cluster crashes, `TiCDC` can restore data in the downstream cluster within 5 minutes, given the conditions that before the disaster the replication status of `TiCDC` is normal and the replication lag is small. It allows RTO <= 5 min and P95 RPO <= 10s.

`TiCDC` replication lag increases in the following scenarios:
- The `TPS` increases significantly in a short time.
- Large or long transactions occur in the upstream.
- The `TiKV` or `TiCDC` cluster in the upstream is reloaded or upgraded.
- Time-consuming `DDL` statements, such as add index, are executed in the upstream.
- The `PD` is configured with aggressive scheduling strategies, resulting in frequent transfer of `Region` leaders, or frequent `Region` merge or `Region` split operations.