Replication and Binary Logging Options and Variables •A limitation to preserving the commit order on the replica can occur if statement-based replication is in use, and both transactional and non- transactional storage engines participate in a non-XA transaction that is rolled back on the source. Normally, non-XA transactions that are rolled back on the source are not replicated to the replica, but in this particular situation, the transaction might be replicated to the replica. If this does happen, a multithreaded replica without binary logging does not handle the transaction rollback, so the commit order on the replica diverges from the relay log order of the transactions in that case. • slave_rows_search_algorithms • slave_skip_errors 3536 When preparing batches of rows for row-based logging and replication, this system variable controls how the rows are searched for matches, in particular whether hash scans are used. The use of this system variable is now deprecated. The default setting  INDEX_SCAN,HASH_SCAN  is optimal for performance and works correctly in all scenarios. See Section 17.5.1.27, “Replication and Row Searches” . Command-Line Format --slave-skip-errors=name System Variable slave_skip_errors Scope Global Dynamic No SET_VAR  Hint Applies No Type String Default Value OFF Valid Values OFF [list of error codes] all Command-Line Format --slave-rows-search-algorithms=value Deprecated 8.0.18 System Variable slave_rows_search_algorithms Scope Global Dynamic Yes SET_VAR  Hint Applies No Type Set Default Value INDEX_SCAN,HASH_SCAN Valid Values TABLE_SCAN,INDEX_SCAN INDEX_SCAN,HASH_SCAN TABLE_SCAN,HASH_SCAN TABLE_SCAN,INDEX_SCAN,HASH_SCAN (equivalent to INDEX_SCAN,HASH_SCAN)