Aligning TiCDC DDL Handling with TiDB v8.3.0’s enable_fast_create_table
Behavior
#11816
Labels
affects-8.5
This bug affects the 8.5.x(LTS) versions.
area/ticdc
Issues or PRs related to TiCDC.
severity/major
type/bug
The issue is confirmed as a bug.
Background
In TiDB versions prior to v8.3.0, when
enable_fast_create_table=on
, thebatch create tables
DDL job would transition directly to theJobStateSynced
state upon completion, bypassing theJobStateDone
state. Moreover,create table
DDL jobs would be written directly to thetidb_ddl_history
table instead of thetidb_ddl_job
table.As of TiDB v8.3.0, this behavior has been standardized:
batch create tables
DDL jobs now follow the same lifecycle as other DDL jobs, including transitioning through theJobStateDone
state, and are written to thetidb_ddl_job
table.This change allows TiCDC to stop listening to the
tidb_ddl_history
table, simplifying its architecture and reverting to the implementation prior to the introduction of theenable_fast_create_table
feature.Problem Statement
Previously, TiCDC handled both
JobStateDone
andJobStateSynced
states forcreate table
DDL jobs. This dual handling introduced potential redundancy and complexity, as TiCDC might process the same DDL job twice—once in theJobStateDone
state and again in theJobStateSynced
state.This issue became more pronounced after the changes introduced in #11733, where TiCDC would process the same
create table
DDL job twice, once for theJobStateDone
state and again for theJobStateSynced
state. The detailed reason for this issue is a long story. In the early implementation ofenable_fast_create_table v1
in TiDB, whenenable_fast_create_table=on
, theCREATE TABLE
DDL is only written into thetidb_ddl_history
table. Therefore, TiCDC must monitor thetidb_ddl_history
table to capture theCREATE TABLE
DDL. However, whenenable_fast_create_table=off
, TiDB cannot guarantee that the commit TS of the DDL written to thetidb_ddl_history
table is less than the commit TS of the DMLs related to that table. Consequently, TiCDC must monitor thetidb_ddl_job
table to capture theCREATE TABLE
DDL, as this table ensures that the commit TS of its DDLs is always in order with the commit TS of the DMLs.Thus, for the same DDL, when
enable_fast_create_table=off
, TiCDC will receive it twice—once from thetidb_ddl_job
table and once from thetidb_ddl_history
table. TiCDC cannot perceive whetherenable_fast_create_table
ison
oroff
on the upstream TiDB.Additionally, processing
JobStateDone
DDL jobs instead ofJobStateSynced
DDL jobs can significantly reduce latency. The transition of a DDL job fromJobStateDone
toJobStateSynced
in TiDB involves:JobStateSynced
state after TiKV transactions are committed.This sequence introduces delays that can be avoided if TiCDC processes the
JobStateDone
state directly.Finally, TiCDC's reliance on the
tidb_ddl_history
table for capturingcreate table
DDL changes was necessitated by theenable_fast_create_table=on
behavior, where DDL jobs would only be written totidb_ddl_history
in theJobStateSynced
state. With TiDB v8.3.0's changes, this is no longer required, and TiCDC can revert to monitoring only thetidb_ddl_job
table.Proposed Solution
Update TiCDC to process only
JobStateDone
DDL jobs forcreate table
operations, leveraging the new behavior in TiDB v8.3.0. This will:create table
DDL job is processed twice by TiCDC.tidb_ddl_history
table, reverting to the pre-enable_fast_create_table
implementation.Action Items
JobStateDone
state forcreate table
operations.JobStateSynced
forcreate table
DDL jobs.tidb_ddl_history
table in TiCDC.Impact
This change will:
create table
DDL job twice due to ddl_puller.go(ticdc): fix DDLs are ignored when schema versions are out of order #11733.tidb_ddl_history
table.The text was updated successfully, but these errors were encountered: