If a statement produces the same error (identical error codę) on both the master and the slave, the
error is logged, but replication continues.
If a statement produces different errors on the master and the slave, the slave SQL thread terminates,
and the slave writes a message to its error log and waits for the database administrator to decide what
to do about the error. This includes the case that a statement produces an error on the master or the
slave, but not both. To address the issue, connect to the slave manually and determine the cause of
the problem. SHOW SLAVE STATUS is useful for this. Then fix the problem and run
START SLAVE. For
example, you might need to create a nonexistent table before you can start the slave again.
If this error codę validation behavior is not desirable, some or all errors can be masked out (ignored)
with the —slave-skip-errors [2021] option.
For nontransactional storage engines such as My ISAM, it is possible to have a statement that only
partially updates a table and returns an error codę. This can happen, for example, on a multiple-row
insert that has one rowviolating a key constraint, or if a long update statement is killed after updating
some of the rows. If that happens on the master, the slave expects execution of the statement to resułt
in the same error codę. If it does not, the slave SQL thread stops as described previously.
If you are replicating between tables that use different storage engines on the master and slave, keep
in mind that the same statement might produce a different error when run against one version of the
table, but not the other, or might cause an error for one version of the table, but not the other. For
example, sińce My ISAM ignores foreign key constraints, an INSERT or UPDATE statement accessing
an InnoDB table on the master might cause a foreign key violation but the same statement performed
on a My ISAM version of the same table on the slave would produce no such error, causing replication to stop.