From 12ada1a152c8355eeda0d68be3fcb76f6c44a5d3 Mon Sep 17 00:00:00 2001 From: Joyinqin Date: Wed, 26 May 2021 12:29:16 +0800 Subject: [PATCH 1/4] Update troubleshoot-ticdc.md --- ticdc/troubleshoot-ticdc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 8c953caf00449..08d3712647896 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -318,9 +318,9 @@ If you encounter an error above, it is recommended to use BR to restore the incr ## When the downstream of a changefeed is a database similar to MySQL and TiCDC executes a time-consuming DDL statement, all other changefeeds are blocked. How should I handle the issue? 1. Pause the execution of the changefeed that contains the time-consuming DDL statement. Then you can see that other changefeeds are no longer blocked. -2. Search for the `apply job` field in the TiCDC log and confirm the `StartTs` of the time-consuming DDL statement. +2. Search for the `apply job` field in the TiCDC log and confirm the `start-ts` of the time-consuming DDL statement. 3. Manually execute the DDL statement in the downstream. After the execution finishes, go on performing the following operations. -4. Modify the changefeed configuration and add the above `StartTs` to the `ignore-txn-start-ts` configuration item. +4. Modify the changefeed configuration and add the above `start-ts` to the `ignore-txn-start-ts` configuration item. 5. Resume the paused changefeed. ## After I upgrade the TiCDC cluster to v4.0.8, the `[CDC:ErrKafkaInvalidConfig]Canal requires old value to be enabled` error is reported when I execute a changefeed From dc76cfb962c943e80c30e715ff78e54977d968c9 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Fri, 28 May 2021 18:06:31 +0800 Subject: [PATCH 2/4] Update ticdc/troubleshoot-ticdc.md Co-authored-by: JoyinQ <56883733+Joyinqin@users.noreply.github.com> --- ticdc/troubleshoot-ticdc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 08d3712647896..e34c34ebb49b9 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -318,7 +318,7 @@ If you encounter an error above, it is recommended to use BR to restore the incr ## When the downstream of a changefeed is a database similar to MySQL and TiCDC executes a time-consuming DDL statement, all other changefeeds are blocked. How should I handle the issue? 1. Pause the execution of the changefeed that contains the time-consuming DDL statement. Then you can see that other changefeeds are no longer blocked. -2. Search for the `apply job` field in the TiCDC log and confirm the `start-ts` of the time-consuming DDL statement. +2. Search for the `apply job` field in the TiCDC log and confirm the `start-ts` of the time-consuming DDL statement. If the TiCDC version is earlier than or equal to v4.0.13 and the `start-ts` is not printed in the log, you can query the TiDB DDL history and find the `binlog.TableInfo.update_timestamp` field of the DDL statement. This field is the required `start-ts`. 3. Manually execute the DDL statement in the downstream. After the execution finishes, go on performing the following operations. 4. Modify the changefeed configuration and add the above `start-ts` to the `ignore-txn-start-ts` configuration item. 5. Resume the paused changefeed. From 9d2a689488dae75ffe9f3212a289f9fc18d7a890 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Fri, 28 May 2021 18:08:10 +0800 Subject: [PATCH 3/4] Update ticdc/troubleshoot-ticdc.md --- ticdc/troubleshoot-ticdc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index e34c34ebb49b9..47408cab32d82 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -318,7 +318,7 @@ If you encounter an error above, it is recommended to use BR to restore the incr ## When the downstream of a changefeed is a database similar to MySQL and TiCDC executes a time-consuming DDL statement, all other changefeeds are blocked. How should I handle the issue? 1. Pause the execution of the changefeed that contains the time-consuming DDL statement. Then you can see that other changefeeds are no longer blocked. -2. Search for the `apply job` field in the TiCDC log and confirm the `start-ts` of the time-consuming DDL statement. If the TiCDC version is earlier than or equal to v4.0.13 and the `start-ts` is not printed in the log, you can query the TiDB DDL history and find the `binlog.TableInfo.update_timestamp` field of the DDL statement. This field is the required `start-ts`. +2. Search for the `apply job` field in the TiCDC log and confirm the `start-ts` of the time-consuming DDL statement. If the TiCDC version is earlier than or equal to v4.0.13 and the `start-ts` is not printed in the log, you can query the TiDB DDL history and find the `binlog.TableInfo.update_timestamp` field of the DDL statement. This field is the required `start-ts`. 3. Manually execute the DDL statement in the downstream. After the execution finishes, go on performing the following operations. 4. Modify the changefeed configuration and add the above `start-ts` to the `ignore-txn-start-ts` configuration item. 5. Resume the paused changefeed. From b8d265b377031983221aef744bad84c0d9f48bf2 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Fri, 28 May 2021 18:08:33 +0800 Subject: [PATCH 4/4] Update ticdc/troubleshoot-ticdc.md --- ticdc/troubleshoot-ticdc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 47408cab32d82..e34c34ebb49b9 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -318,7 +318,7 @@ If you encounter an error above, it is recommended to use BR to restore the incr ## When the downstream of a changefeed is a database similar to MySQL and TiCDC executes a time-consuming DDL statement, all other changefeeds are blocked. How should I handle the issue? 1. Pause the execution of the changefeed that contains the time-consuming DDL statement. Then you can see that other changefeeds are no longer blocked. -2. Search for the `apply job` field in the TiCDC log and confirm the `start-ts` of the time-consuming DDL statement. If the TiCDC version is earlier than or equal to v4.0.13 and the `start-ts` is not printed in the log, you can query the TiDB DDL history and find the `binlog.TableInfo.update_timestamp` field of the DDL statement. This field is the required `start-ts`. +2. Search for the `apply job` field in the TiCDC log and confirm the `start-ts` of the time-consuming DDL statement. If the TiCDC version is earlier than or equal to v4.0.13 and the `start-ts` is not printed in the log, you can query the TiDB DDL history and find the `binlog.TableInfo.update_timestamp` field of the DDL statement. This field is the required `start-ts`. 3. Manually execute the DDL statement in the downstream. After the execution finishes, go on performing the following operations. 4. Modify the changefeed configuration and add the above `start-ts` to the `ignore-txn-start-ts` configuration item. 5. Resume the paused changefeed.