# Percona backup to create secondary mysql 5.7 instance now has many duplicate delete and write errors during replication

**URL:** <https://forums.percona.com/t/percona-backup-to-create-secondary-mysql-5-7-instance-now-has-many-duplicate-delete-and-write-errors-during-replication/28188>\
**Category:** Percona XtraBackup\
**Created:** [February 2, 2024, 3:51am UTC](https://forums.percona.com/t/percona-backup-to-create-secondary-mysql-5-7-instance-now-has-many-duplicate-delete-and-write-errors-during-replication/28188 "2024-02-02T03:51:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jaye\_McCracken](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jaye_mccracken/32/14044_2.png) [@Jaye\_McCracken](https://forums.percona.com/u/Jaye_McCracken)\
**Post date:** [February 2, 2024, 3:51am UTC](https://forums.percona.com/t/percona-backup-to-create-secondary-mysql-5-7-instance-now-has-many-duplicate-delete-and-write-errors-during-replication/28188/1 "2024-02-02T03:51:28Z")

</div>

Hi,

EDIT: [AH this may be my issue](https://forums.percona.com/t/errors-after-starting-new-slave-server-replication-using-percona-xtrabackups-backup/4064/3):

> Make sure that you are getting your replication coordinates from xtrabackup\_slave\_info (points to the master of the slave you backed up) and not xtrabackup\_binlog\_info (points to the slave itself that you backed up).

I’m using percona xtrabackup 2.4 to migrate my mysql 5.7 db to a secondary server for replication.  
The backup appears to restore correctly, but when replication is set up I end up with these two types of error repeatedly as it tries to catch up:

```auto
Could not execute Write_rows event on table db.table; Duplicate entry 'content' for key 'column.index', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY;

```

and

```auto
Could not execute Delete_rows event on table db.table; Can't find record in 'notifications', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;

```

In both cases it’s trying to modify a row to its existing state, ie, write a row that already exists or delete a row that is already deleted.

This is the command I’m using for the backup:

```auto
xtrabackup --backup \
    --no-timestamp \
    --target-dir="{{ backup_dir }}" \
    --user="{{ mysql_root_user }}" \
    --host=127.0.0.1 \
    --password="{{ secrets.mysql_root_password.value }}"

```

I use the binlog details from the `xtrabackup_binlog_info` file in the backup to inform the change master command.

With the same DB this mysqldump command functions fine and results in clean replication:

```auto
mysqldump --all-databases --flush-logs --master-data --routines --single-transaction --triggers \
    -u "{{ mysql_root_user }}" \
    -h "127.0.0.1" \
    -p"{{ secrets.mysql_root_password.value }}" \
    > "{{ backup_dir }}/backup.sql"

```

Ideally I can figure out how to resolve the replication issue as I’d prefer the non-locking effect of xtrabackup.

I assume I’m just missing a setting in the percona CLI or I need to adjust the binlog details from the ones provided by the backup.

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [February 2, 2024, 5:46pm UTC](https://forums.percona.com/t/percona-backup-to-create-secondary-mysql-5-7-instance-now-has-many-duplicate-delete-and-write-errors-during-replication/28188/2 "2024-02-02T17:46:00Z")

</div>

Marking solved due to OP edit link

---

<div class="post-metadata">

**Author:** ![Jaye\_McCracken](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jaye_mccracken/32/14044_2.png) [@Jaye\_McCracken](https://forums.percona.com/u/Jaye_McCracken)\
**Post date:** [February 5, 2024, 5:12am UTC](https://forums.percona.com/t/percona-backup-to-create-secondary-mysql-5-7-instance-now-has-many-duplicate-delete-and-write-errors-during-replication/28188/3 "2024-02-05T05:12:37Z")

</div>

Turns out I actually had the opposite issue, but working through this did resolve it.

They were dealing with taking a backup of a replica, intending to replicate with the primary, but ending up trying to replicate from the replica instead.

I’m taking a backup of a primary (that was previously a replication), so I accidentally took the previous replication info (pointing me toward the binlog details of the previous master db).

So I actually wanted to use `xtrabackup_binlog_info` instead of `xtrabackup_slave_info`.