Subtask tracing issue for undo based eventually consistent replication

[amyangfei]

Basic Design

TiCDC supports a tso-map feature, which means TiCDC can replicate data to a consistent state periodically (under the conditions that upstream TiDB is available), and persists a tso map which records a consistent state between upstream and downstream. Based on that premise, when upstream meets disaster, if we can provide a way to recover downstream to the latest TSO in tso-map, we can get an eventually consistent state in downstream.

The undo feature is built in TiCDC and reuses the ability of current TiCDC, including kv events handling, raw kv data decoding, flow control etc. Note the EventFeed API based undo in TiCDC is suitable for TiDB (>=4.0) only.

This is an alternative solution for eventually consistent replication compared to #2351

Task breakdown

8 weeks totally

• Add a new recovery mode in TiCDC. 6weeks

  • Support to run cdc cli undo from the cli entry, including integration with the following parts. 1week
  • Refactor the puller module can run independently, including kv client management, schema management, sorter and mounter, to support pulls kv events and generate sorted row events. (looks like running a TiCDC server in the background) 3weeks
    • An alternative solution is to run a cdc server in downstream cluster, and add a new kind of replication task, which is undo task, this will reuse most of the current TiCDC logic.
  • Support to generate undo SQLs from given row events. 1week
  • Support undo sink. 1week

• Overall test and benchmark. 2weeks

  • Combine the whole features, integration tests. 1week
  • Benchmark tests, test the RTO and RPO. 1week

• Unified undo framework for non-TiDB. (won't do currently)

[amyangfei]

This feature won't do