If a statement produces the same error (identical error code) on both the source and the replica, the error is logged, but replication continues.
If a statement produces different errors on the source and the
replica, the replication SQL thread terminates, and the replica
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
source or the replica, but not both. To address the issue,
connect to the replica manually and determine the cause of the
REPLICA STATUS (or before MySQL 8.0.22,
STATUS) is useful for this. Then fix the problem and
REPLICA (or before MySQL 8.0.22,
SLAVE). For example, you might need to create a
nonexistent table before you can start the replica again.
If a temporary error is recorded in the replica's error log, you do not necessarily have to take any action suggested in the quoted error message. Temporary errors should be handled by the client retrying the transaction. For example, if the replication SQL thread records a temporary error relating to a deadlock, you do not need to restart the transaction manually on the replica, unless the replication SQL thread subsequently terminates with a nontemporary error message.
If this error code validation behavior is not desirable, some or
all errors can be masked out (ignored) with the
For nontransactional storage engines such as
MyISAM, it is possible to have a
statement that only partially updates a table and returns an
error code. This can happen, for example, on a multiple-row
insert that has one row violating a key constraint, or if a long
update statement is killed after updating some of the rows. If
that happens on the source, the replica expects execution of the
statement to result in the same error code. If it does not, the
replication SQL thread stops as described previously.
If you are replicating between tables that use different storage
engines on the source and replica, 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,
MyISAM ignores foreign key constraints,
UPDATE statement accessing an
InnoDB table on the source might cause a
foreign key violation but the same statement performed on a
MyISAM version of the same table on the
replica would produce no such error, causing replication to
Beginning with MySQL 8.0.31, replication filter rules are applied first, prior to making any privilege or row format checks, making it possible to filter out any transactions that fail validation; no checks are performed and thus no errors are raised for transactions which have been filtered out. This means that the replica can accept only that part of the database to which a given user has been granted access (as long as any updates to this part of the database use the row-based replication format). This may be helpful when performing an upgrade or when migrating to a system or application that uses administration tables to which the inbound replication user does not have access. See also Section 17.2.5, “How Servers Evaluate Replication Filtering Rules”.