# Percona delayed replica problem **URL:** \ **Category:** Percona XtraDB Cluster\ **Tags:** percona, new-release\ **Created:** [February 27, 2024, 7:10am UTC](https://forums.percona.com/t/percona-delayed-replica-problem/28755 "2024-02-27T07:10:09Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![sven.star](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sven.star](https://forums.percona.com/u/sven.star)\ **Post date:** [February 27, 2024, 7:10am UTC](https://forums.percona.com/t/percona-delayed-replica-problem/28755/1 "2024-02-27T07:10:10Z")
Hi, we just upgraded 3 node percona xtradb cluster 5.7 to 8.0.35 (GTID=ON) running on debian 11. We have an extra host with percona server 8.0.35 as delayed replica ( [Replication with Global Transaction Identifiers). Everything was working fine until master upgrade. Now the delay replica is failing over and over with: 2024-02-20T20:49:06.058500Z 25 [ERROR] [MY-010584] [Repl] Replica SQL for channel ‘’: Worker 1 failed executing transaction ‘200be2d2-10da-11e4-b7d3-3bbbce82e394:10788071’ at source logbinlog.000002, end\_log\_pos 16805332; Could not execute Update\_rows event on table live.events; Can’t find record in ‘events’, Error\_code: 1032; handler error HA\_ERR\_KEY\_NOT\_FOUND; the event’s source log binlog.000002, end\_log\_pos 16805332, Error\_code: MY-001032 This transaction is an update query for some field in table live.events. After analysis we found out that the transaction with insert query (should happen before update transaction) was just skipped (not committed on delay replica) , so the transaction above can’t update field in table. If we don’t use delay on replication it works fine. Any idea where the problem is? ---
**Author:** ![Yunus](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yunus/32/6430_2.png) [@Yunus](https://forums.percona.com/u/Yunus)\ **Post date:** [February 27, 2024, 8:05am UTC](https://forums.percona.com/t/percona-delayed-replica-problem/28755/2 "2024-02-27T08:05:01Z")
Hi Sven, Do you mean that the replica is committing in incorrect order? What is the value of `replica-preserve-commit-order` on a replica? ---
**Author:** ![sven.star](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sven.star](https://forums.percona.com/u/sven.star)\ **Post date:** [February 29, 2024, 11:09am UTC](https://forums.percona.com/t/percona-delayed-replica-problem/28755/3 "2024-02-29T11:09:35Z")
Hey Yunus, sorry for late answer, was testing different setups. Yes, it looks like the replica is not committing in the right order. We tested 2 delayed replicas, replicating from same master with different settings: slave\_parallel\_workers | 4 replica\_preserve\_commit\_order | ON and slave\_parallel\_workers | 1 replica\_preserve\_commit\_order | ON both replicas failing with the same error. Replica\_IO\_Running: Yes Replica\_SQL\_Running: No Last\_Errno: 1032 Last\_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction ‘200be2d2-10da-11e4-b7d3-3bbbce82e394:18845523’ at source log binlog.006029, end\_log\_pos 152871615. See error log and/or performance\_schema.replication\_applier\_status\_by\_worker table for more details about this failure or others, if any. ---
**Author:** ![sven.star](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sven.star](https://forums.percona.com/u/sven.star)\ **Post date:** [March 1, 2024, 8:01am UTC](https://forums.percona.com/t/percona-delayed-replica-problem/28755/4 "2024-03-01T08:01:54Z")
I fixed the problem. I can’t tell which option in mysql conf was causing it, but after changing the config delayed replica runs without problem. The working config: [mysqld@db4h] socket = /run/mysqld\_db4h/mysqld.sock pid-file = /run/mysqld\_db4h/mysqld.pid datadir = /data/db4h/mysql-data tmpdir = /data/db4h/mysql-tmp log-error = /var/log/mysql/db4h.err general-log-file = /var/log/mysql/db4h.log bind-address = 0.0.0.0 port = 3306 character-set-server = utf8mb3 collation-server = utf8\_unicode\_ci mysqlx = 0 default-authentication-plugin = mysql\_native\_password sql-mode = NO\_ENGINE\_SUBSTITUTION log\_error\_verbosity = 2 super\_read\_only = 1 lc-messages-dir = /usr/share/mysql skip-external-locking max\_allowed\_packet = 1G thread\_stack = 192K thread\_cache\_size = 8 innodb\_redo\_log\_capacity = 500M innodb\_log\_buffer\_size = 16M innodb\_buffer\_pool\_size = 4G max-heap-table-size = 16G log\_bin = binlog relay\_log = relay-bin max\_relay\_log\_size = 10M max\_binlog\_size = 1G log\_replica\_updates = 1 gtid\_mode = ON enforce\_gtid\_consistency relay\_log\_recovery = ON binlog\_expire\_logs\_seconds = 864000 server-id = 100