content_image/662662.jpg
Shutting down a replica cleanly is safe because it keeps track of where it left off. However, be careful that the replica does not have temporary tables open; see Section 17.5.1.31, “Replication and Temporary Tables” . Unclean shutdowns might produce problems, especially if the disk cache was not flushed to disk before the problem occurred: 

•For transactions, the replica commits and then updates relay-log.info . If an unexpected exit occurs between these two operations, relay log processing proceeds further than the information file indicates and the replica re-executes the events from the last transaction in the relay log after it has been restarted. 

•A similar problem can occur if the replica updates relay-log.info  but the server host crashes before the write has been flushed to disk. To minimize the chance of this occurring, set sync_relay_log_info=1  in the replica my.cnf  file. Setting sync_relay_log_info  to 0 causes no writes to be forced to disk and the server relies on the operating system to flush the file from time to time. 

The fault tolerance of your system for these types of problems is greatly increased if you have a good uninterruptible power supply. 

## 17.5.1.29 Replica Errors During Replication 

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 problem. SHOW REPLICA | SLAVE STATUS  is useful for this. Then fix the problem and run START REPLICA | SLAVE . For example, you might need to create a nonexistent table before you can start the replica again. 

<img src='content_image/662662.jpg'>

## Note 

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 --slave-skip-errors  option. 

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, since MyISAM  ignores foreign key constraints, an INSERT  or 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 stop. 

## 17.5.1.30 Replication and Server SQL Mode 

