### 17.2.3 Replication Threads

[17.2.3.1 Monitoring Replication Main Threads](replication-threads-monitor-main.html)
[17.2.3.2 Monitoring Replication Applier Worker Threads](replication-threads-monitor-worker.html)

 MySQL replication capabilities are implemented using three main threads, one on the source server and two on the replica:

* **Binary log dump thread.**  The source creates a thread to send the binary log contents to a replica when the replica connects. This thread can be identified in the output of [`SHOW PROCESSLIST`](show-processlist.html) on the source as the `Binlog Dump` thread.

   The binary log dump thread acquires a lock on the source's binary log for reading each event that is to be sent to the replica. As soon as the event has been read, the lock is released, even before the event is sent to the replica.

* **Replication I/O receiver thread.**  When a [`START REPLICA`](start-replica.html) statement is issued on a replica server, the replica creates an I/O (receiver) thread, which connects to the source and asks it to send the updates recorded in its binary logs.

   The replication receiver thread reads the updates that the source's `Binlog Dump` thread sends (see previous item) and copies them to local files that comprise the replica's relay log.

   The state of this thread is shown as `Slave_IO_running` in the output of [`SHOW SLAVE STATUS`](show-slave-status.html).

* **Replication SQL applier thread.**  The replica creates an SQL (applier) thread to read the relay log that is written by the replication receiver thread and execute the transactions contained in it.

 There are three main threads for each source/replica connection. A source that has multiple replicas creates one binary log dump thread for each currently connected replica, and each replica has its own replication receiver and applier threads.

 A replica uses two threads to separate reading updates from the source and executing them into independent tasks. Thus, the task of reading transactions is not slowed down if the process of applying them is slow. For example, if the replica server has not been running for a while, its receiver thread can quickly fetch all the binary log contents from the source when the replica starts, even if the applier thread lags far behind. If the replica stops before the SQL thread has executed all the fetched statements, the receiver thread has at least fetched everything so that a safe copy of the transactions is stored locally in the replica's relay logs, ready for execution the next time that the replica starts.

 You can enable further parallelization for tasks on a replica by setting the system variable [`replica_parallel_workers`](replication-options-replica.html#sysvar_replica_parallel_workers) (from MySQL 8.0.26) or [`slave_parallel_workers`](replication-options-replica.html#sysvar_slave_parallel_workers) (before MySQL 8.0.26) to a value greater than 0 (the default). When this system variable is set, the replica creates the specified number of worker threads to apply transactions, plus a coordinator thread to manage them. If you are using multiple replication channels, each channel has this number of threads. A replica with [`replica_parallel_workers`](replication-options-replica.html#sysvar_replica_parallel_workers) or [`slave_parallel_workers`](replication-options-replica.html#sysvar_slave_parallel_workers) set to a value greater than 0 is called a multithreaded replica. With this setup, transactions that fail can be retried.

Note

 Multithreaded replicas are not currently supported by NDB Cluster, which silently ignores the setting for this variable. See [Section 23.7.3, “Known Issues in NDB Cluster Replication”](mysql-cluster-replication-issues.html) for more information.

