Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: dm可以从mysql迁移到mysql吗，我测试mysql到mysql迁移使用DM居然成功了
【TiDB Usage Environment】Production Environment / Testing / PoC
【TiDB Version】
【Reproduction Path】What operations were performed when the problem occurred
【Encountered Problem: Problem Phenomenon and Impact】
【Resource Configuration】Go to TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
【Attachments: Screenshots / Logs / Monitoring】
Why not? If the target is TiDB, it’s also SQL writing, and it can be switched to MySQL as well.
The official use case mentioned is for MySQL protocol databases to TiDB. I thought the data must interact with TiKV.
Theoretically, there shouldn’t be any issues, but wouldn’t direct MySQL master-slave replication be simpler?
Tested it myself for fun.
It disguises itself as a slave to obtain incremental data.
Isn’t it great that you succeeded?
Theoretically, there should definitely be no problem.
Although there may be bugs
DM reads the binlog and then reproduces the SQL in the downstream, which is equivalent to a MySQL replica, so it is definitely possible~~
Sometimes there will be issues 
If there is no comprehensive testing, be cautious about going into production.
No one has done this, after all, there is a big difference between persisting MySQL and TiDB.
I understand the operation of DM as follows:
First, it fetches the binlog from the upstream (TableMapEvent, WriteRowsEvent, etc.)
Then it constructs SQL based on the table from its own cache.
Finally, it executes the SQL downstream.
Since TiDB is compatible with MySQL syntax, it will naturally succeed in this scenario (downstream MySQL).
However, the target end is TiDB by default, which may have specific optimizations and might not cover all scenarios.
My experience is not enough, I need to modify the DM code.
It is possible, but not necessary.
The underlying layer of TiDB is MySQL, so using TiDB tools with a MySQL database should be feasible.
My cousin said that although there might be bugs.
DM is a disguised MySQL slave. It captures all DML statements from the binlog, converts them into corresponding SQL, and then executes them on TiDB. Therefore, it can synchronize with TiDB. However, since DM is a dedicated synchronization tool for TiDB, for MySQL to MySQL synchronization, it is still recommended to use direct master-slave replication.
|
username: Sunward
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: