From 49285c0196e5157807aa2243d4cb7c673abfa770 Mon Sep 17 00:00:00 2001 From: CharlesCheung96 Date: Mon, 2 Sep 2024 12:04:33 +0800 Subject: [PATCH 1/8] add wait async ddl description --- ticdc/ticdc-ddl.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index e4f7eb37450c..12326ef2de9f 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -50,6 +50,8 @@ summary: 了解 TiCDC 支持同步的 DDL 和一些特殊情况 为了减小对 Changefeed 同步延迟的影响，如果下游是 TiDB，TiCDC 会异步执行创建和添加索引的 DDL 操作，即 TiCDC 将 `ADD INDEX` 和 `CREATE INDEX` DDL 同步到下游执行后，会立刻返回，而不会等待 DDL 操作完成。这样可以避免阻塞后续的 DML 执行。 +当 `ADD INDEX` 和 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，可能因为新的 DDL 长期被阻塞在 queueing 状态导致重复执行同一条 DDL，重试时间过长时还会导致同步任务失败。从 v8.3.0 开始，如果 TiCDC 拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 + > **注意：** > > - 如果下游 DML 的执行依赖于未完成同步的索引，DML 可能会执行得很慢，进而影响 TiCDC 的同步延迟。 From 518b4a706f6eafa1609098b54ca2b1a3213d051f Mon Sep 17 00:00:00 2001 From: CharlesCheung <61726649+CharlesCheung96@users.noreply.github.com> Date: Mon, 2 Sep 2024 14:27:51 +0800 Subject: [PATCH 2/8] Apply suggestions from code review --- ticdc/ticdc-ddl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index 12326ef2de9f..5b0164df86d6 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -50,7 +50,7 @@ summary: 了解 TiCDC 支持同步的 DDL 和一些特殊情况 为了减小对 Changefeed 同步延迟的影响，如果下游是 TiDB，TiCDC 会异步执行创建和添加索引的 DDL 操作，即 TiCDC 将 `ADD INDEX` 和 `CREATE INDEX` DDL 同步到下游执行后，会立刻返回，而不会等待 DDL 操作完成。这样可以避免阻塞后续的 DML 执行。 -当 `ADD INDEX` 和 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，可能因为新的 DDL 长期被阻塞在 queueing 状态导致重复执行同一条 DDL，重试时间过长时还会导致同步任务失败。从 v8.3.0 开始，如果 TiCDC 拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 +当 `ADD INDEX` 和 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 queueing 状态导致被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.3.0 开始，如果 TiCDC 拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 > **注意：** > From d3b7044dcd2187b4e4e30091ecdee2921f76ce8b Mon Sep 17 00:00:00 2001 From: CharlesCheung <61726649+CharlesCheung96@users.noreply.github.com> Date: Mon, 2 Sep 2024 15:07:29 +0800 Subject: [PATCH 3/8] Update ticdc/ticdc-ddl.md --- ticdc/ticdc-ddl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index 5b0164df86d6..2dc06e62a581 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -50,7 +50,7 @@ summary: 了解 TiCDC 支持同步的 DDL 和一些特殊情况 为了减小对 Changefeed 同步延迟的影响，如果下游是 TiDB，TiCDC 会异步执行创建和添加索引的 DDL 操作，即 TiCDC 将 `ADD INDEX` 和 `CREATE INDEX` DDL 同步到下游执行后，会立刻返回，而不会等待 DDL 操作完成。这样可以避免阻塞后续的 DML 执行。 -当 `ADD INDEX` 和 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 queueing 状态导致被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.3.0 开始，如果 TiCDC 拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 +当 `ADD INDEX` 和 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 queueing 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.3.0 开始，如果 TiCDC 拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 > **注意：** > From c7a3ee486c3e0bcc8d887dbedbd237472ad8830e Mon Sep 17 00:00:00 2001 From: CharlesCheung <61726649+CharlesCheung96@users.noreply.github.com> Date: Mon, 2 Sep 2024 19:58:34 +0800 Subject: [PATCH 4/8] Update ticdc/ticdc-ddl.md --- ticdc/ticdc-ddl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index 2dc06e62a581..80d3d52de581 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -50,7 +50,7 @@ summary: 了解 TiCDC 支持同步的 DDL 和一些特殊情况 为了减小对 Changefeed 同步延迟的影响，如果下游是 TiDB，TiCDC 会异步执行创建和添加索引的 DDL 操作，即 TiCDC 将 `ADD INDEX` 和 `CREATE INDEX` DDL 同步到下游执行后，会立刻返回，而不会等待 DDL 操作完成。这样可以避免阻塞后续的 DML 执行。 -当 `ADD INDEX` 和 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 queueing 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.3.0 开始，如果 TiCDC 拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 +当 `ADD INDEX` 和 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 queueing 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.4.0 开始，如果 TiCDC 拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 > **注意：** > From 169ef83832c4ab4120df7ea01c186a288fd0c9b5 Mon Sep 17 00:00:00 2001 From: CharlesCheung <61726649+CharlesCheung96@users.noreply.github.com> Date: Tue, 10 Sep 2024 19:06:02 +0800 Subject: [PATCH 5/8] Update ticdc/ticdc-ddl.md --- ticdc/ticdc-ddl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index 80d3d52de581..eaf884bb18e5 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -50,7 +50,7 @@ summary: 了解 TiCDC 支持同步的 DDL 和一些特殊情况 为了减小对 Changefeed 同步延迟的影响，如果下游是 TiDB，TiCDC 会异步执行创建和添加索引的 DDL 操作，即 TiCDC 将 `ADD INDEX` 和 `CREATE INDEX` DDL 同步到下游执行后，会立刻返回，而不会等待 DDL 操作完成。这样可以避免阻塞后续的 DML 执行。 -当 `ADD INDEX` 和 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 queueing 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.4.0 开始，如果 TiCDC 拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 +当 `ADD INDEX` 或 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 queueing 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.4.0 开始，如果拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 > **注意：** > From 3555ee5d91c1a27457a9528ab1b242f621dc76bf Mon Sep 17 00:00:00 2001 From: CharlesCheung <61726649+CharlesCheung96@users.noreply.github.com> Date: Thu, 12 Sep 2024 10:18:24 +0800 Subject: [PATCH 6/8] Update ticdc/ticdc-ddl.md --- ticdc/ticdc-ddl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index eaf884bb18e5..7b6f2a31193a 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -50,7 +50,7 @@ summary: 了解 TiCDC 支持同步的 DDL 和一些特殊情况 为了减小对 Changefeed 同步延迟的影响，如果下游是 TiDB，TiCDC 会异步执行创建和添加索引的 DDL 操作，即 TiCDC 将 `ADD INDEX` 和 `CREATE INDEX` DDL 同步到下游执行后，会立刻返回，而不会等待 DDL 操作完成。这样可以避免阻塞后续的 DML 执行。 -当 `ADD INDEX` 或 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 queueing 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.4.0 开始，如果拥有下游数据库的 `SUPER` 权限，TiCDC 可以通过 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，直到索引创建完成后再继续同步，这期间同步任务的延迟会上升，但避免了同步任务失败。 +当 `ADD INDEX` 或 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 `queueing` 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.4.0 开始，如果拥有下游数据库的 `SUPER` 权限，TiCDC 会定期执行 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，等到索引创建完成后再继续同步。这期间虽然同步任务的延迟会加剧，但避免了同步任务失败的问题。 > **注意：** > From d177f17a8aaf2bab1008f6d6dac1d29144ff79fc Mon Sep 17 00:00:00 2001 From: CharlesCheung96 Date: Thu, 12 Sep 2024 10:24:41 +0800 Subject: [PATCH 7/8] fix --- ticdc/ticdc-split-update-behavior.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index 5ed4ce010102..dcf8b894bd3d 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -118,7 +118,7 @@ COMMIT; 从 v6.5.10、v7.1.6、v7.5.3 和 v8.1.1 开始，使用非 MySQL Sink 时，TiCDC 支持通过 `output-raw-change-event` 参数控制是否拆分主键或唯一键 `UPDATE` 事件，详情见 GitHub issue [#11211](https://github.com/pingcap/tiflow/issues/11211)。这个参数的具体行为是： - 当 `output-raw-change-event = false` 时，如果 `UPDATE` 事件的主键或者非空唯一索引的列值发生改变，TiCDC 会将该其拆分为 `DELETE` 和 `INSERT` 两条事件，并确保所有事件按照 `DELETE` 事件在 `INSERT` 事件之前的顺序进行排序。 -- 当 `output-raw-change-event = true` 时，TiCDC 不拆分 `UPDATE` 事件。注意，当表的主键为聚簇索引时，对主键的更新会在 TiDB 中拆分为 `DELETE` 和 `INSERT` 两个事件，该行为不受 `output-raw-change-event` 参数的影响。 +- 当 `output-raw-change-event = true` 时，TiCDC 不拆分 `UPDATE` 事件，消费侧需负责处理[非 MySQL Sink 拆分主键或唯一键 `UPDATE` 事件](/ticdc/ticdc-split-update-behavior.md#非-mysql-sink-拆分主键或唯一键-update-事件)中说明的问题，否则可能出现数据不一致风险。注意，当表的主键为聚簇索引时，对主键的更新会在 TiDB 中拆分为 `DELETE` 和 `INSERT` 两个事件，该行为不受 `output-raw-change-event` 参数的影响。 #### Release 6.5 的兼容性 From da769bd7c4a43d920c712f1d87bf8acc9e5f3f80 Mon Sep 17 00:00:00 2001 From: Lilian Lee Date: Mon, 14 Oct 2024 11:28:36 +0800 Subject: [PATCH 8/8] Update wording --- ticdc/ticdc-ddl.md | 2 +- ticdc/ticdc-split-update-behavior.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index 7b6f2a31193a..6ecc925ec0b1 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -50,7 +50,7 @@ summary: 了解 TiCDC 支持同步的 DDL 和一些特殊情况 为了减小对 Changefeed 同步延迟的影响，如果下游是 TiDB，TiCDC 会异步执行创建和添加索引的 DDL 操作，即 TiCDC 将 `ADD INDEX` 和 `CREATE INDEX` DDL 同步到下游执行后，会立刻返回，而不会等待 DDL 操作完成。这样可以避免阻塞后续的 DML 执行。 -当 `ADD INDEX` 或 `CREATE INDEX` DDL 在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 `queueing` 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.4.0 开始，如果拥有下游数据库的 `SUPER` 权限，TiCDC 会定期执行 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，等到索引创建完成后再继续同步。这期间虽然同步任务的延迟会加剧，但避免了同步任务失败的问题。 +当 `ADD INDEX` 或 `CREATE INDEX` DDL 操作在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 `queueing` 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.4.0 开始，如果拥有下游数据库的 `SUPER` 权限，TiCDC 会定期执行 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，等到索引创建完成后再继续同步。这期间虽然同步任务的延迟会加剧，但避免了同步任务失败的问题。 > **注意：** > diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index dcf8b894bd3d..1d8dd4cbfe84 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -118,7 +118,7 @@ COMMIT; 从 v6.5.10、v7.1.6、v7.5.3 和 v8.1.1 开始，使用非 MySQL Sink 时，TiCDC 支持通过 `output-raw-change-event` 参数控制是否拆分主键或唯一键 `UPDATE` 事件，详情见 GitHub issue [#11211](https://github.com/pingcap/tiflow/issues/11211)。这个参数的具体行为是： - 当 `output-raw-change-event = false` 时，如果 `UPDATE` 事件的主键或者非空唯一索引的列值发生改变，TiCDC 会将该其拆分为 `DELETE` 和 `INSERT` 两条事件，并确保所有事件按照 `DELETE` 事件在 `INSERT` 事件之前的顺序进行排序。 -- 当 `output-raw-change-event = true` 时，TiCDC 不拆分 `UPDATE` 事件，消费侧需负责处理[非 MySQL Sink 拆分主键或唯一键 `UPDATE` 事件](/ticdc/ticdc-split-update-behavior.md#非-mysql-sink-拆分主键或唯一键-update-事件)中说明的问题，否则可能出现数据不一致风险。注意，当表的主键为聚簇索引时，对主键的更新会在 TiDB 中拆分为 `DELETE` 和 `INSERT` 两个事件，该行为不受 `output-raw-change-event` 参数的影响。 +- 当 `output-raw-change-event = true` 时，TiCDC 不拆分 `UPDATE` 事件，消费侧需负责处理[非 MySQL Sink 拆分主键或唯一键 `UPDATE` 事件](/ticdc/ticdc-split-update-behavior.md#非-mysql-sink-拆分主键或唯一键-update-事件)中说明的问题，否则可能出现数据不一致的风险。注意，当表的主键为聚簇索引时，对主键的更新会在 TiDB 中拆分为 `DELETE` 和 `INSERT` 两个事件，该行为不受 `output-raw-change-event` 参数的影响。 #### Release 6.5 的兼容性