While MySQL replication is running, it might throw errors like below:
140502 1:56:38 [ERROR] Slave SQL: Could not execute Write_rows event on table DB_name.table_name; Duplicate entry '138114741' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000054, end_log_pos 880389787, Error_code: 1062
Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000054' position 880388660
Sometimes it happens that the MySQL replication stops because some statements received from the master fail when replayed on a slave. Luckily, however, this isn’t always the case as sometimes the failing statements don’t affect the data or might only affect data that isn’t important or is removed frequently (for example tables containing temporary data); in such cases then you may not need to rebuild the slave or re-sync with the Percona tools (which perform a time consuming comparison operation -especially on large tables- and might cause high load on both master and slave, up to causing locks and various issues depending on the usage of the servers at the time and the resources available); you can instead get the slave up and running again very quickly by simply skipping the failing statements, provided that these statements can be safely ignored as well as any data they might affect.
This can be done by temporarily stopping the slave, then instructing MySQL to skip one or more statements received from the master, and eventually starting the slave again.
mysql> stop slave;
Query OK, 0 rows affected (0.10 sec)
mysql> set global SQL_SLAVE_SKIP_COUNTER = 1;
Query OK, 0 rows affected (0.00 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
But the ultimate fix would be to replicate the faulty table from other DB server
Mysqldump:
mysqldump -u user -p DB_name table_name > table_name.sql
Restore:
mysql -u user -p db_name < /path/to/table_name.sql
