Replication and Binary Logging Options and Variables Default Value OFF For multithreaded replicas (replicas on which  slave_parallel_workers  is set to a value greater than 0), setting  slave_preserve_commit_order=1  ensures that transactions are executed and committed on the replica in the same order as they appear in the replica’s relay log. This prevents gaps in the sequence of transactions that have been executed from the replica’s relay log, and preserves the same transaction history on the replica as on the source (with the limitations listed below). This variable has no effect on replicas for which multithreading is not enabled. Up to and including MySQL 8.0.18, setting  slave_preserve_commit_order=1  requires that binary logging ( log_bin ) and replica update logging ( log_slave_updates ) are enabled on the replica, which are the default settings from MySQL 8.0. From MySQL 8.0.19, binary logging and replica update logging are not required on the replica to set  slave_preserve_commit_order=1 , and can be disabled if wanted. In all releases, setting  slave_preserve_commit_order=1  requires that slave_parallel_type  is set to  LOGICAL_CLOCK , which is  not  the default setting. Before changing the value of  slave_preserve_commit_order  and  slave_parallel_type , the replication SQL thread (for all replication channels if you are using multiple replication channels) must be stopped. When  slave_preserve_commit_order=0  is set, which is the default, the transactions that a multithreaded replica applies in parallel may commit out of order. Therefore, checking for the most recently executed transaction does not guarantee that all previous transactions from the source have been executed on the replica. There is a chance of gaps in the sequence of transactions that have been executed from the replica’s relay log. This has implications for logging and recovery when using a multithreaded replica. See Section 17.5.1.34, “Replication and Transaction Inconsistencies”  for more information. When  slave_preserve_commit_order=1  is set, the executing worker thread waits until all previous transactions are committed before committing. While a given thread is waiting for other worker threads to commit their transactions, it reports its status as  Waiting for preceding transaction to commit . With this mode, a multithreaded replica never enters a state that the source was not in. This supports the use of replication for read scale-out. See Section 17.4.5, “Using Replication for Scale-Out” . Note •In releases before MySQL 8.0.19,  slave_preserve_commit_order=1  does not preserve the order of statements with an  IF EXISTS  clause when the object concerned does not exist. These might commit before transactions that precede them in the relay log, which might result in gaps in the sequence of transactions that have been executed from the replica’s relay log. • slave_preserve_commit_order=1  does not preserve the order of non- transactional DML updates. These might commit before transactions that precede them in the relay log, which might result in gaps in the sequence of transactions that have been executed from the replica’s relay log. • slave_preserve_commit_order=1  does not preserve the commit order and transaction history if the replica uses filters on its binary log, such as  -- binlog-do-db . • slave_preserve_commit_order=1  does not prevent source binary log position lag, where  Exec_master_log_pos  is behind the position up to which transactions have been executed. See Section 17.5.1.34, “Replication and Transaction Inconsistencies” . 3535