Replication and Binary Logging Options and Variables specify that write sets are used for parallelization in place of timestamps, if a write set is available for the transaction and gives improved results compared to timestamps. When  slave_preserve_commit_order=1  is set, you can only use  LOGICAL_CLOCK . When your replication topology uses multiple levels of replicas,  LOGICAL_CLOCK  may achieve less parallelization for each level the replica is away from the source. You can reduce this effect by using binlog_transaction_dependency_tracking  on the source to specify that write sets are used instead of timestamps for parallelization where possible. • DATABASE : Transactions that update different databases are applied in parallel. This value is only appropriate if data is partitioned into multiple databases which are being updated independently and concurrently on the source. There must be no cross-database constraints, as such constraints may be violated on the replica. • slave_parallel_workers When binary log transaction compression is enabled using the  binlog_transaction_compression system variable, if  slave_parallel_type  is set to  DATABASE , all the databases affected by the transaction are mapped before the transaction is scheduled. The use of binary log transaction compression with the  DATABASE  policy can reduce parallelism compared to uncompressed transactions, which are mapped and scheduled for each event. Command-Line Format --slave-parallel-workers=# System Variable slave_parallel_workers Scope Global Dynamic Yes SET_VAR  Hint Applies No Type Integer Default Value 0 Minimum Value 0 Maximum Value 1024 Enables multithreading on the replica and sets the number of applier threads for executing replication transactions in parallel. When the value is a number greater than 0, the replica is a multithreaded replica with the specified number of applier threads, plus a coordinator thread to manage them. If you are using multiple replication channels, each channel has this number of threads. Multithreaded replicas are not currently supported by NDB Cluster, which silently ignores the setting for this variable. See Section 23.6.3, “Known Issues in NDB Cluster Replication” , for more information. Retrying of transactions is supported when multithreading is enabled on a replica. When slave_preserve_commit_order=1 , transactions on a replica are externalized on the replica in Note 3533