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

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.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.

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

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.

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 = 1032

But 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 up

Also 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_ip

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