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.
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.
First, examine your MySQL error log to see the exact binary log position and statement that caused the error:
# On the slave server
tail -50 /var/log/mysql/error.logLook 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.
Connect to your MySQL slave and check the detailed replication status:
SHOW SLAVE STATUS\GLook 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.
Identify which records exist on master vs slave by checking the statement that failed:
-- 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.
If you suspect table corruption, stop replication and repair the table:
-- 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.
If the slave is significantly out of sync, the safest approach is a full resync:
# 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.
For replication errors caused by non-critical data or monitoring tables, you can skip individual errors:
-- 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:
[mysqld]
slave-skip-errors = 1032But understand that this silently ignores replication errors, which can lead to data loss.
Confirm that replication has resumed properly:
-- 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 upAlso verify data consistency:
-- 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_ipIf data matches and both processes are running, replication is healthy.
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:
-- 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.
EE_WRITE (3): Error writing file
How to fix "EE_WRITE (3): Error writing file" in MySQL
CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters
How to fix "CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters" in MySQL
CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed
How to fix "CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed" in MySQL
ERROR 1146: Table 'database.table' doesn't exist
How to fix "ERROR 1146: Table doesn't exist" in MySQL
ERROR 1040: Too many connections
How to fix "ERROR 1040: Too many connections" in MySQL