Error in DM Synchronization

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

Original topic: dm同步出错

| username: TiDBer_QHSxuEa1

When testing DM MySQL data synchronization to TiDB, an error occurred. How can this be resolved?

| username: Billmay表妹 | Original post link

Paste the error message text!

It looks like some settings are not configured properly~

| username: ShawnYan | Original post link

Sure, please provide the text you need translated.

| username: okenJiang | Original post link

This is because GTID is not enabled.

According to the error message, it encountered a duplicate key. You can check the binlog.

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

The meaning of this error is:
The primary key record 1001 already exists in the table im_cost_info and cannot be inserted again.

One possibility is: the upstream truncated and deleted the data in the table, but the downstream may not have synchronized the truncate event. Therefore, when the upstream inserts the record again, this error occurs.

| username: redgame | Original post link

Did you import it repeatedly? Conflict?

| username: 像风一样的男子 | Original post link

Setting safe-mode: true will prevent primary key conflicts.

| username: cy6301567 | Original post link

Has it been resolved? What was the issue? I also want to avoid pitfalls.

| username: Hacker007 | Original post link

Run tiup dmctl resume-task taskname. Sometimes there are false positives. If you can’t resolve it, check the dm-worker log to see which table is causing the issue.

| username: TiDB_C罗 | Original post link

You can temporarily skip it with the following command:
tiup dmctl binlog skip taskName -b mysql-bin000003:3270
Was data written to TiDB?

| username: zhanggame1 | Original post link

Primary key conflict, how could it happen? Are both databases being written to?

| username: TiDBer_QHSxuEa1 | Original post link

The issue has been resolved. The data duplication was caused by simultaneous writes from upstream and downstream. You need to evaluate this data. If you don’t want to keep it, you can simply skip it using tiup dmctl --master-addr < > skip <task_name> -b "<binlog file name:position>". If you want to keep it, handle this data first, then resume the task using resume-task.

| username: TiDBer_QHSxuEa1 | Original post link

Yes, both sides have writes.

| username: 天蓝色的小九 | Original post link

Primary key conflict, both sides are writing.

| username: system | Original post link

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