[TiDB Usage Environment] Production / Testing / PoC
[TiDB Version]
[Reproduction Path] Operations performed that led to the issue
Executed on MySQL side:
ALTER TABLE t3 ADD COLUMN new_col INT UNIQUE;
dm error
“Message”: “startLocation: [position: (, 0), gtid-set: ], endLocation: [position: (mysql-bin.000003, 1850), gtid-set: 33fe3796-a10b-11ed-ab4a-000c29acdd18:1-16]: gen insert sqls failed, sourceTable: test.t3, targetTable: test.t3: Column count doesn’t match value count: 2 (columns) vs 3 (values)”,
“RawCause”: “”,
Manually executed on tiup:
ALTER TABLE t3 ADD COLUMN new_col INT;
ALTER TABLE t3 ADD UNIQUE(new_col);
MySQL side insert statement error:
insert into t3 values(6,‘dddd’,1);
Checked that the table structures on both sides are consistent
I didn’t understand the question. The error says that the upstream and downstream table structures are inconsistent, one has 2 columns and the other has 3 columns.
Generally, you just need to compare the table structures to see where the discrepancy is, alter the table to keep the number of columns consistent between upstream and downstream, and then resume the task to continue.
It’s not necessary to skip.
Skipping might lead to data inconsistency between upstream and downstream.
Is it a production environment? If it is production data, it is best to stop the task, delete the four tables corresponding to this task under the dm_meta database, and completely clean up the downstream data before re-importing. Because even if you skip the erroneous SQL, it may lead to inconsistencies between upstream and downstream, which could be unacceptable in a production environment.
If it is a test environment or consistency is not highly required, you can choose to skip the SQL through commands.
If the table is very large and you don’t want to rebuild the entire task, and you must perform incremental repair, you can use this MySQL command-line tool to check the SQL statements at the corresponding positions in the binlog file. Then, based on this, repair the downstream table to ensure that the two are consistent. The SQL in the binlog can then be executed smoothly.
The upgrade has been completed, so there’s no need to set up a lower version again. If this error occurs again in the future, you can troubleshoot it following this approach. Thank you.
|
username: 路在何chu
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: