How to fix ERROR 1032: Can't find record in MySQL

MySQLADVANCEDHIGHUpdated Dec 22, 2025· 189 views

ERROR 1032 occurs when MySQL cannot locate a record during DELETE or UPDATE operations, commonly due to replication drift, table corruption, or incorrect WHERE clauses. This guide shows how to identify the root cause and resync your databases.

Quick fix

Fixes 1032

# On the slave server
tail -50 /var/log/mysql/error.log
  1. Check the MySQL error log for context
  2. Check the slave replication status
  3. Verify data consistency using SELECT
  4. Repair table corruption (if applicable)
mysql — error
# On the slave server
tail -50 /var/log/mysql/error.log
ERROR 1032: Can't find record

What this error means

MySQL error 1032 (SQLSTATE: HY000, ER_KEY_NOT_FOUND) means the database system cannot find a specific record in a table during a data manipulation operation. This error occurs most frequently in replication scenarios where the master and slave databases are out of sync—the master successfully performs an operation on a row that doesn't exist on the slave. It can also occur in standalone databases when there's table corruption, incorrect WHERE clause conditions, or foreign key constraint issues. The error prevents data inconsistency by stopping the operation rather than proceeding with incomplete information.

Typical symptoms

  • Replication stops with "Could not execute update_rows event" in slave status
  • DELETE or UPDATE queries fail with "Can't find record in 'table_name'" message
  • Slave lag increases while slave is stopped waiting for manual intervention
  • Binary log position shows the exact statement that failed on the replica
  • SELECT query for the same row returns results on master but not on slave
  • Application receives MySQL error 1032 when executing DML statements

Common causes

  1. Replication drift: Master and slave databases are out of sync due to errant transactions or missed updates
  2. Master abnormal restart: Causes slave replication to report 1032 errors when trying to apply changes
  3. Table corruption: Physical corruption of table files prevents MySQL from locating records correctly
  4. Foreign key constraint violations: Attempting to delete/update a record referenced by another table
  5. Incorrect WHERE clause: The condition in DELETE/UPDATE doesn't match any existing records
  6. Slave read-only permission not properly configured: Prevents some operations on replicas
  7. Missing indexes or stale query optimization: Causes MySQL to miss existing records during lookups

How to fix "ERROR 1032: Can't find record"

1Check the MySQL error log for context

First, examine your MySQL error log to see the exact binary log position and statement that caused the error:

bash
# On the slave server
tail -50 /var/log/mysql/error.log

Look for lines mentioning ERROR 1032 and note the binary log file and position. This tells you exactly which master statement the slave couldn't execute.

2Check the slave replication status

Connect to your MySQL slave and check the detailed replication status:

sql
SHOW SLAVE STATUS\G

Look for:
- Last_Error: The exact error message
- Relay_Log_File and Relay_Log_Pos: Where replication stopped
- Master_Log_File and Read_Master_Log_Pos: How far behind the slave is

This tells you whether the issue is on the master or slave side.

3Verify data consistency using SELECT

Identify which records exist on master vs slave by checking the statement that failed:

sql
-- On MASTER: Check if the record exists
SELECT * FROM table_name WHERE id = 123;

-- On SLAVE: Check if the same record exists
SELECT * FROM table_name WHERE id = 123;

If the record exists on master but not on slave, the slave is missing data. If it doesn't exist on either, a previous operation didn't replicate correctly.

4Repair table corruption (if applicable)

If you suspect table corruption, stop replication and repair the table:

sql
-- On SLAVE, stop replication first
STOP SLAVE;

-- Check and repair the corrupted table
CHECK TABLE table_name;
REPAIR TABLE table_name;

-- Restart replication
START SLAVE;

Use CHECK TABLE to diagnose issues, and REPAIR TABLE to fix them. For InnoDB tables, use OPTIMIZE TABLE instead.

5Resync the slave database (comprehensive fix)

If the slave is significantly out of sync, the safest approach is a full resync:

bash
# On MASTER: Create a backup
mysqldump -u root -p --all-databases --master-data > backup.sql

# Copy to slave server
scp backup.sql slave:/tmp/

# On SLAVE: Stop replication and restore
STOP SLAVE;
mysql -u root -p < /tmp/backup.sql

# Check the binary log position from the backup
grep "CHANGE MASTER" /tmp/backup.sql

# Use that position to reset replication
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=12345;
START SLAVE;

This ensures the slave is an exact copy of the master and replication can proceed cleanly.

6Skip the error as a temporary workaround (replication only)

For replication errors caused by non-critical data or monitoring tables, you can skip individual errors:

sql
-- On SLAVE only
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

This skips the current failing statement and moves to the next one. Repeat if necessary.

WARNING: Only use this for non-critical data. Skipping errors leaves your databases inconsistent. Use this only as a temporary measure before performing a full resync.

For persistent error skipping in production (not recommended), add to /etc/mysql/my.cnf:

ini
[mysqld]
slave-skip-errors = 1032

But understand that this silently ignores replication errors, which can lead to data loss.

7Verify replication health after fixing

Confirm that replication has resumed properly:

sql
-- Check slave status
SHOW SLAVE STATUS\G

-- Verify Slave_IO_Running and Slave_SQL_Running are both YES
-- Check Seconds_Behind_Master to confirm slave is catching up

Also verify data consistency:

sql
-- Generate checksums of all tables to compare master vs slave
-- Using pt-table-checksum (part of Percona Toolkit)
pt-table-checksum --databases=mydb h=master_ip
pt-table-checksum --databases=mydb h=slave_ip

If data matches and both processes are running, replication is healthy.

Advanced notes

For replication with foreign key constraints, ensure the foreign_key_checks variable is consistent between master and slave. Some operations may cause error 1032 if constraints differ:

sql
-- Check current setting
SHOW VARIABLES LIKE "foreign_key_checks";

-- Disable temporarily for repair (master only)
SET GLOBAL foreign_key_checks = OFF;
-- ... perform repairs ...
SET GLOBAL foreign_key_checks = ON;

For multi-threaded replication (slave_parallel_workers > 0), error 1032 can sometimes occur due to race conditions in applying events out of order. If you frequently see this error despite consistent data, consider reducing the number of parallel workers.

MySQL also provides --slave-skip-errors configuration option in the configuration file, but this is dangerous in production as it silently ignores replication errors. Always prefer explicit error handling and full resyncs over silent error suppression.

In MySQL 8.0.32+, the error message was improved to include more context about which row couldn't be found, making debugging easier.

Frequently asked questions

What does "1032" mean?
MySQL error 1032 (SQLSTATE: HY000, ER_KEY_NOT_FOUND) means the database system cannot find a specific record in a table during a data manipulation operation. This error occurs most frequently in replication scenarios where the master and slave databases are out of sync—the master successfully performs an operation on a row that doesn't exist on the slave. It can also occur in standalone databases when there's table corruption, incorrect WHERE clause conditions, or foreign key constraint issues.
How do I fix "1032"?
ERROR 1032 occurs when MySQL cannot locate a record during DELETE or UPDATE operations, commonly due to replication drift, table corruption, or incorrect WHERE clauses. This guide shows how to identify the root cause and resync your databases.
What causes "1032"?
Replication drift: Master and slave databases are out of sync due to errant transactions or missed updates Master abnormal restart: Causes slave replication to report 1032 errors when trying to apply changes Table corruption: Physical corruption of table files prevents MySQL from locating records correctly
Is the "1032" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading