[DM Incremental Migration] How to Determine if Incremental Migration Has Caught Up

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

Original topic: 【DM增量迁移】DM增量迁移时,如何判断增量已经追平

| username: Tiny

[TiDB Usage Environment] Production Environment
[TiDB Version] v7.5.1
I am using DM to migrate Tencent Cloud TDSQL to TiDB v7.5.1 cluster.
The query-status shows the task as follows:
“subTaskStatus”: [
“name”: “bbq_erp”,
“stage”: “Running”,
“unit”: “Sync”,
“result”: null,
“unresolvedDDLLockID”: “”,
“sync”: {
“totalEvents”: “3574846”,
“totalTps”: “64”,
“recentTps”: “1”,
“masterBinlog”: “(mysql-bin.233845, 120404143)”,
“masterBinlogGtid”: “0217d8fb-1ed5-11ed-b943-b8cef6abbc3c:1-6919153953,32339aac-2fcf-11ee-be9c-b8cef627f928:1-4331140045,e95a68aa-0bc7-11ed-b15f-b8cef6d419ca:1-486299789”,
“syncerBinlog”: “(mysql-bin.233845, 117560188)”,
“syncerBinlogGtid”: “0217d8fb-1ed5-11ed-b943-b8cef6abbc3c:1-6919153953,32339aac-2fcf-11ee-be9c-b8cef627f928:1-4331138119,e95a68aa-0bc7-11ed-b15f-b8cef6d419ca:1-486299789”,
“blockingDDLs”: [
“unresolvedGroups”: [
“synced”: false,
“binlogType”: “remote”,
“secondsBehindMaster”: “0”,
“blockDDLOwner”: “”,
“conflictMsg”: “”,
“totalRows”: “3574846”,
“totalRps”: “64”,
“recentRps”: “1”
“validation”: null

I want to know which parameter indicates whether the incremental migration is complete? The “synced” parameter has been false for over 24 hours.
I hope to migrate the upper-layer business to the TiDB cluster after the incremental migration is complete.

| username: TiDBer_QHSxuEa1 | Original post link

“stage”: “Running”, – The task is in progress
“unit”: “Sync”, – The task status is synchronization. If your synchronization task is “all”, there will be three statuses (dump, load, sync). If it is incremental, there will be one status (sync).

“masterBinlog” and “syncerBinlog” indicate the current binary log position of the master database and the position to which the slave database has synchronized the master binary log.

In my understanding, this task is already in the synchronization phase. That “false” is not used to synchronize the task status. In my production environment, this status is also “false” and it has no impact.

| username: yiduoyunQ | Original post link

Sync catching up with master is true, otherwise it is false. If there is no data being written upstream, just wait.

| username: TiDBer_QHSxuEa1 | Original post link

If you really can’t figure it out, check this out:
TiDB Data Migration Query Task Status | PingCAP Documentation Center

| username: tidb菜鸟一只 | Original post link

Isn’t it written here? The master’s binlog has reached mysql-bin.233845, 120404143, while the downstream cluster is still at mysql-bin.233845, 117560188. This is basically caught up. You need to stop the upstream database’s operations first for it to catch up completely.

| username: DBAER | Original post link

You can also look at the corresponding GTID and POS. This is continuous upstream writing, right?

| username: dba远航 | Original post link

“synced”: false, should be true

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

Your status should be basically caught up.

“unit”: “Sync”,
“secondsBehindMaster”: “0”,

This “secondsBehindMaster” indicates the delay between the time recorded in the binlog and the current time. A value of 0 means the delay is in milliseconds. Of course, it could be anywhere from 1-999ms. To see the exact delay, you can check the Grafana dashboard of the DM cluster. You can see the delay of each task relative to the upstream binlog.

“masterBinlog”: “(mysql-bin.233845, 120404143)”,
“syncerBinlog”: “(mysql-bin.233845, 117560188)”,

The binlog difference is just these.

| username: system | Original post link

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