Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 使用dm下游字段比上游多报Column count doesn’t match value count错误
[TiDB Usage Environment] Production Environment
[TiDB Version] v6.5.1
DM Version: v5.4
Background:
TiDB is used as a downstream replica, and it has always had more columns than MySQL. It has been running fine until today when it suddenly reported a “Column count doesn’t match value count” error.
The issue has been resolved by running the following command:
tiup dmctl --master-addr 192.168.10.148:8261 operate-schema set -s xxxx xxxx -dxxxx -t h_thirdcommunityid_communityid 1.sql
There are two purposes for this post:
- To report a bug in the official documentation. The usage in this document is incorrect:
下游存在更多列的迁移场景 | PingCAP 文档中心
If it is binlog-schema, the correct syntax should be:
dmctl binlog-schema update <task-name> <database> <table> [schema-file] [flags]
- Why did this error suddenly occur during normal operation? According to this article:
管理 TiDB Data Migration 迁移表的表结构 | PingCAP 文档中心
This issue should only occur when task-mode=incremental, but this task was started with task-mode=all and has been running for a very long time.
Have you tried restarting the dm-worker process? Also, make sure the mapping relationship is correct.
Regarding your first point, you mentioned an error in the official documentation. It appears that the usage provided in the documentation is incorrect. The correct syntax for updating the binlog-schema using dmctl should be:
dmctl binlog-schema update <task-name> <database> <table> [schema-file] [flags]
Regarding your second point, you mentioned that the error occurred suddenly in a task that has been running for a long time with task-mode=all. The issue you linked to in the TiDB documentation indicates that the “Column count doesn’t match value count” error typically occurs in task-mode=incremental. However, in your case, since you are using task-mode=all, it is unexpected to encounter this error.
chatgpt? Moderator, please manage it.
There was no restart, it was running normally before, so the mapping should be correct.
This ChatGPT reply is really disgusting, it has no substantial reference value, and it writes a lot, disrupting normal replies.
I encountered this problem before. Finally, I saw in the binlog that there was an execution of “create table if not exists”. Filtering “create table” from the binlog filter can also cause schema changes.
The solution is the same as yours, just change the schema back directly. 
In your situation, after executing “create table if not exists,” does DM report an error for the newly created table, or does it also report errors for other tables?
The table that was just created will not have its schema changed if it hasn’t been executed. However, the “create table if not exists” statement in the upstream has nothing to do with whether the table exists or not. In other words, if the table already exists upstream and you execute the “create table if not exists” statement again, even if this statement doesn’t actually do anything, the corresponding downstream schema will still change.
|
username: zzw6776
|
username: 
|
username: 
|
username: 
|
username: