Description:
If a table has a FK that is referencing the same table, deleting a row breaks the replication (error on the replica, the replica stops)
Most probably, this is the regression caused by commit 9e1e77fa (WL#11249 - Support Foreign Key Cascading Operation in server). Bug is not present in 9.5
How to repeat:
Two nodes: primary -> async replication -> replica
On primary execute:
CREATE TABLE t1 (
f1 INT NOT NULL PRIMARY KEY,
f2 INT,
FOREIGN KEY (f2)
REFERENCES t1(f1)
ON DELETE CASCADE
) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1, 1), (2, 1);
DELETE FROM t1 WHERE f1 = 1;
The result on replica:
2026-03-06T09:45:00.907942Z 11 [ERROR] [MY-010584] [Repl] Replica SQL for channel '': Worker 1 failed executing transaction '9b25c286-193f-11f1-8052-c84bd64e0288:6' at source log binlog.000001, end_log_pos 1750; Could not execute Delete_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's source log binlog.000001, end_log_pos 1750, Error_code: MY-001032
2026-03-06T09:45:56.928104Z 10 [Warning] [MY-010584] [Repl] Replica SQL for channel '': ... The replica coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: MY-001756
© 2026, Oracle Corporation and/or its affiliates
Description: If a table has a FK that is referencing the same table, deleting a row breaks the replication (error on the replica, the replica stops) Most probably, this is the regression caused by commit 9e1e77fa (WL#11249 - Support Foreign Key Cascading Operation in server). Bug is not present in 9.5 How to repeat: Two nodes: primary -> async replication -> replica On primary execute: CREATE TABLE t1 ( f1 INT NOT NULL PRIMARY KEY, f2 INT, FOREIGN KEY (f2) REFERENCES t1(f1) ON DELETE CASCADE ) ENGINE=InnoDB; INSERT INTO t1 VALUES (1, 1), (2, 1); DELETE FROM t1 WHERE f1 = 1; The result on replica: 2026-03-06T09:45:00.907942Z 11 [ERROR] [MY-010584] [Repl] Replica SQL for channel '': Worker 1 failed executing transaction '9b25c286-193f-11f1-8052-c84bd64e0288:6' at source log binlog.000001, end_log_pos 1750; Could not execute Delete_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's source log binlog.000001, end_log_pos 1750, Error_code: MY-001032 2026-03-06T09:45:56.928104Z 10 [Warning] [MY-010584] [Repl] Replica SQL for channel '': ... The replica coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: MY-001756