Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: DM的case-sensitive参数疑问
[Test Environment for TiDB] Testing
[TiDB Version] v6.5.1
[Reproduction Path]
I saw this parameter in the DM documentation:
case-sensitive: false # Whether schema/table is case-sensitive
But in practice, Schema in TiDB is case-insensitive, for example:
This means that if a MySQL database has two tables tt1 and TT1, they will definitely conflict when placed in TiDB.
What is the significance of the case-sensitive parameter in DM?
Based on actual testing, regardless of whether this parameter is set to true or false, start-task will always prompt a table name conflict.
If the lower_case_table_names parameter is set to 0, TiDB will be case-sensitive, right?
This should be related to the upstream. For the filter, if the upstream has two tables named ttl and TTL, and the table in the filter configuration is ttl, while case-sensitive=false, then both ttl and TTL tables will be synchronized. During synchronization, synchronization failures may occur because TiDB will report errors such as the table already exists or primary key conflicts. If case-sensitive=true, then only the ttl table will be synchronized, and no errors will be reported during synchronization. It seems the difference lies here.
From your inquiry, it is certain that your upstream MySQL is case-sensitive.
DM only exports the data and uses the upstream binlog logs.
The downstream TiDB database must also maintain case sensitivity, otherwise, it will report an error: the object you mentioned already exists.
###################################
However, your TiDB might be case-insensitive.
For the ttl TTL extracted by DM from the binlog, if the uppercase table name is converted to lowercase, it will report an error. You can check the error log for details.
Hello: Could you please send the log of the error when creating a case-sensitive table upstream on this DM link?
What you mentioned is the configuration in the DM upstream data source, while mine is the configuration in the Task. I feel that their functions are different.
No error when creating case-sensitive tables in upstream MySQL, but DM reports duplicate table names during synchronization.
Execute the following in MySQL: show variables like '%case%'; and post the results.
It seems to have the same function, both targeting routing or filtering rules. Otherwise, I can’t think of any other use. According to MySQL’s understanding, it’s like one rule applies to the transmission to the relay-log, and the other applies to the reading and application of the relay-log.
I think the problem is that the tidb-server process is not running. You can check if the process is running with the following command:
ps -ef | grep tidb-server
If it is not running, you can start it with the following command:
systemctl start tidb-server
If that’s the case, then it can only be said that the documentation is not clear enough 
I really can’t think of any other use either.
lower_case_table_names = 0 Case sensitive. Source end. So there will be no error.
Please also send the parameters of TiDB.
The source table is not case-insensitive. When writing to TiDB through DM, you need to add case-sensitive; otherwise, DM synchronization will report an error.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: hey-hoho
|
username: 
|
username: 
|
username: 
|
username: