DM Synchronization Failure

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: DM同步失败

| username: terry0219

[Test Environment for TiDB] Testing
[TiDB Version] 7.5
[Reproduction Path] Simulate changing the upstream MySQL instance address connected by DM-worker
[Encountered Problem: Phenomenon and Impact]
When using DM for synchronization, after changing the upstream MySQL address and restarting the task, an error message appears: “Message”: “get binlog event error: ERROR 1236 (HY000): Could not find first log file name in binary log index file”

The steps were followed according to this document:

| username: Billmay表妹 | Original post link

Is the upstream MySQL and the downstream TiDB?

| username: terry0219 | Original post link

Yes.

| username: Billmay表妹 | Original post link

Found some content in Chinese.

| username: Billmay表妹 | Original post link

Check this out: tidb dm工具,同步过程中,莫名其妙的报下面这个错误,如何解决 - #8,来自 TiDBer_HJLsvyxd - TiDB 的问答社区

| username: 有猫万事足 | Original post link

Sure, please provide the text you need translated.

| username: dba远航 | Original post link

After changing the upstream address, has the DM configuration been updated?

| username: terry0219 | Original post link

I changed it, but after changing to the new address, this error occurred.
Also, how do I clean up the binlog information in DM? I destroyed and redeployed the DM cluster, but after starting the task, this error still occurred.

| username: terry0219 | Original post link

Which specific DM configuration change are you referring to?

| username: IanWong | Original post link

What is the relationship between your new MySQL and the original MySQL instance? Are you using option 1 or 2 below?

  1. Switching the connection between DM-worker and MySQL instance in a virtual IP environment
  2. Changing the upstream MySQL instance address connected to DM-worker
| username: IanWong | Original post link

The position information is stored under the TiDB instance:
dm_meta.${dm-task-name}_lightning_checkpoint_list
dm_meta.${dm-task-name}_onlineddl
dm_meta.${dm-task-name}_syncer_checkpoint

To completely clean up and start over:

When an exception occurs during data migration and it cannot be recovered, you need to reset the data migration task and re-migrate the data:

  1. Use stop-task to stop the abnormal data migration task.
  2. Clean up the migrated data downstream.
  3. Choose one of the following two ways to restart the data migration task:
  • Modify the task configuration file to specify a new task name, then use start-task {task-config-file} to restart the migration task.
  • Use start-task --remove-meta {task-config-file} to restart the data migration task.
| username: IanWong | Original post link

Did you only change the resource’s IP without modifying the synchronization position information? If you only change the IP without modifying the synchronization position information, DM will use the position of the source MySQL instance to find the binlog, which will definitely result in an error. The synchronization task metadata information is stored in three tables in the TiDB instance dm_meta.${dm-task-name}_*, with table names starting with the task name for identification. If you reconfigure the task without 1) cleaning up the task and metadata information, and 2) creating a new task name, it may cause the new task to obtain the old task’s metadata information, leading to errors.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.