Replication Features and Issues •Any index where the before-image of the row event does not contain all the columns of the index. 1. A primary key. 2. A unique index where every column in the index has a NOT NULL attribute. If more than one such index is available, the algorithm chooses the leftmost of these indexes. 3. Any other index. If more than one such index is available, the algorithm chooses the leftmost of these indexes. If the algorithm is able to select a primary key or a unique index where every column in the index has a NOT NULL  attribute, it uses this index to iterate over the rows in the  UPDATE  or  DELETE  operation. For each row in the row event, the algorithm looks up the row in the index to locate the table record to update. If no matching record is found, it returns the error  ER_KEY_NOT_FOUND  and stops the replication applier thread. If the algorithm was not able to find a suitable index, or was only able to find an index that was non-unique or contained nulls, a hash table is used to assist in identifying the table records. The algorithm creates a hash table containing the rows in the  UPDATE  or  DELETE  operation, with the key as the full before- image of the row. The algorithm then iterates over all the records in the target table, using the selected index if it found one, or else performing a full table scan. For each record in the target table, it determines whether that row exists in the hash table. If the row is found in the hash table, the record in the target table is updated, and the row is deleted from the hash table. When all the records in the target table have been checked, the algorithm verifies whether the hash table is now empty. If there are any unmatched rows remaining in the hash table, the algorithm returns the error  ER_KEY_NOT_FOUND  and stops the replication applier thread. The  slave_rows_search_algorithms  system variable was previously used to control how rows are searched for matches. The use of this system variable is now deprecated, because the default setting, which uses an index scan followed by a hash scan as described above, is optimal for performance and works correctly in all scenarios. It is safe to shut down a replication source server and restart it later. When a replica loses its connection to the source, the replica tries to reconnect immediately and retries periodically if that fails. The default is to retry every 60 seconds. This may be changed with the  CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or  CHANGE MASTER TO  statement (before MySQL 8.0.23). A replica also is able to deal with network connectivity outages. However, the replica notices the network outage only after receiving no data from the source for  slave_net_timeout  seconds. If your outages are short, you may want to decrease  slave_net_timeout . See Section 17.4.2, “Handling an Unexpected Halt of a Replica” . An unclean shutdown (for example, a crash) on the source side can result in the source’s binary log having a final position less than the most recent position read by the replica, due to the source’s binary log file not being flushed. This can cause the replica not to be able to replicate when the source comes back up. Setting  sync_binlog=1  in the source server’s  my.cnf  file helps to minimize this problem because it causes the source to flush its binary log more frequently. For the greatest possible durability and consistency in a replication setup using  InnoDB  with transactions, you should also set innodb_flush_log_at_trx_commit=1 . With this setting, the contents of the  InnoDB  redo log buffer are written out to the log file at each transaction commit and the log file is flushed to disk. Note that the durability of transactions is still not guaranteed with this setting, because operating systems or disk hardware may tell  mysqld  that the flush-to-disk operation has taken place, even though it has not. 3671 17.5.1.28 Replication and Source or Replica Shutdowns If there are no suitable indexes after ruling out these index types, the algorithm does not use an index for the search. If there are suitable indexes, one index is selected from the candidates, in the following priority order: