MySQL Replication Error 1032 & amp; 1052

MySQL Replication is usually used for MySQL services for read/write splitting, HA, hot backup, or incremental operations, and the Master/Slave mechanism is indispensable.

However, errors 1032 and 1052 are reported in many cases.

First 1032.

Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;

The root cause of the 1032 error is the inconsistency between the master and slave databases, which causes the synchronization operation to fail on the slave database.

Currently, I have two situations:

1. During Replication, the master -- binlog-ignore-db = db_name or -- replicate-ignore-db = db_name is used.

Assume that there are two databases pubs and test, and test is ignored. The result is that an SQL statement is executed in the test database on the master database: insert into pubs. tname values (XXXXX );

The master node is successfully executed based on the service configuration. If the master node is not executed, the error 1032 is returned.

2. If the versions of TRIGGER and PROCEDURE are different, for example, a PROCEDURE on the master node writes 5 data records after execution, but only one row of data is written after execution, at this time, the 1032 error will inevitably occur.

Solution:

1 do not use -- binlog-ignore-db and -- replicate-ignore-db = db_name

Change from -- replicate-wild-ignore-table = db_name. %

2. Ensure that the versions of the master-slave TRIGGER and PROCEDURE are consistent.

Let's talk about 1052:

This error is easy to understand. Generally, the Operation connection on the master node is autocommit. As a result, the operation times out and fails. An error will be reported when synchronizing data from the database.

Two methods:

1. Set my. cnf innodb_rollback_on_timeout = 1 on the master and rollback upon timeout.

2. Ignore the 1052. my. cnf -- slave-skip-errors = 1052