🚨 MySQL Error: 'ERROR 1032 (HY000): Can't find record' — Cause, Fix, and Troubleshooting Guide

Overview

ERROR 1032 (HY000) means MySQL tried to apply an UPDATE or DELETE to a row that does not exist where it expected it:

ERROR 1032 (HY000): Can't find record in 'orders'

While it can appear in application code, its most common and disruptive home is replication: a replica applying a row-based binlog event cannot find the “before” image of the row the primary modified. That means the replica’s copy of the table has drifted from the primary — data inconsistency — and replication halts to avoid making it worse.

Symptoms

• Replication SQL thread stops; SHOW REPLICA STATUS shows Last_SQL_Errno: 1032.
• The error names a table and (in row-based logging) a specific position.
• A row that “should” exist on the replica is missing or different.
• Followed a manual write on the replica, a schema skew, or a non-deterministic statement.

Common Root Causes

1. Direct writes on the replica

Someone wrote to the replica directly, so its rows no longer match the primary’s before-images.

2. Replica not truly read-only

Without read_only/super_read_only, an app or migration accidentally modified replica data.

3. Schema drift between primary and replica

Different indexes/columns or an out-of-band ALTER caused row images to mismatch.

4. A prior skipped/partial event

An earlier error was skipped, leaving the replica missing the row a later event depends on.

How to diagnose

Inspect the stopped replica and the failing event:

SHOW REPLICA STATUS\G      -- Last_SQL_Errno, Last_SQL_Error, positions

Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Update_rows event on table appdb.orders;
                Can't find record in 'orders', Error_code: 1032
Relay_Master_Log_File: mysql-bin.000451
Exec_Master_Log_Pos: 88213402

Decode the exact row image from the primary’s binlog:

mysqlbinlog --base64-output=DECODE-ROWS --verbose \
  --start-position=88213402 mysql-bin.000451 | head -40

Compare that row on both servers to confirm the drift:

-- on primary and on replica
SELECT * FROM appdb.orders WHERE id = 90421;

Fixes

Confirm the drift, then reconcile. For a single divergent row you have verified, insert the missing row on the replica so the event can apply, then resume:

-- on replica, after verifying against primary
INSERT INTO appdb.orders (id, /* ...columns... */) VALUES (90421, /* ...values... */);
STOP REPLICA;
START REPLICA;

Skipping the event is a last resort and only masks the problem (GTID example):

-- MySQL 8.0 with GTID: inject an empty transaction to skip (data stays inconsistent!)
STOP REPLICA;
SET GTID_NEXT='<uuid:N>';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START REPLICA;

The correct durable fix for anything beyond one known row is to re-seed the replica from a consistent backup of the primary and restart replication, then lock it down:

[mysqld]
read_only = ON
super_read_only = ON

What to watch out for

• Skipping 1032 events does not fix the inconsistency — it hides it and lets divergence grow. Prefer reconciling or re-seeding.
• Always enforce super_read_only on replicas so nothing writes to them out of band; this prevents the most common cause outright.
• Use tools like pt-table-checksum/pt-table-sync to find and repair drift before it breaks replication.
• Keep schemas identical across the topology; run DDL through the primary (or a controlled rolling process), never directly on replicas.
• Row-based logging (binlog_format=ROW) makes 1032 precise; it points you at the exact drifted row via mysqlbinlog.

Related

• ERROR 1236: fatal error reading from source binlog — a related replication break at the binlog transport layer.
• ERROR 1290: The MySQL server is running with read-only — the guard that prevents the writes causing replica drift.
• ERROR 1146: Table doesn’t exist — schema-skew failures that also stop the SQL thread.