MySQL replication thread

Copy thread

The MySQL replication function is implemented through the following three main threads, one of which is on the source server and the other two on the replica server:

1. Binary log dump thread (Binary log dump thread).
   The source creates a thread to send the contents of the binary log to the replica when the replica is connected. You can identify the thread as a Binlog
   Dump thread in the output of the source by SHOW PROCESSLIST .

   The binary log dump thread acquires a lock on the source binary log in order to read each event to be sent to the replica. Once the event is read, the lock is released, even before the event is sent to the copy.
   
   

2. Replication I/O thread (Replication I/O thread). When a START SLAVE statement is issued on the replica server, the replica creates an I/O thread that connects to the source and asks it to send the updates recorded in its binary log.
   The replication I/O thread reads the update sent by the source Binlog Dump thread (see the previous item) and copies it to the relay log file of the replica.
   In the output of SHOW SLAVE STATUS, the status of the thread is displayed as Slave_IO_running.

3. Replication SQL thread (Replication SQL thread). The replica creates a SQL thread to read the relay log written by the replicate I/O thread and execute the transactions contained therein.

to sum up

Each source/replica connection has these three main threads. A source with multiple replicas creates a binary log dump thread for each currently connected replica, and each replica has its own replication I/O and SQL threads.

The copy uses two threads to separate read updates from the source file and execute them into independent tasks. Therefore, even if the process of applying the transaction is slow, the task of reading the transaction will not slow down. For example, if the replication server has not been running for a period of time, then when the replication starts, its I/O thread can quickly get all the binary log content from the source, even if the SQL thread is far behind it. If the replication stops before the SQL thread executes all the fetched statements, then the I/O thread has at least fetched everything so that the safe copy of the transaction is stored in the local replica's relay log for execution the next time replication starts.

By setting the slave_parallel_workers system variable to a value greater than 0 (the default value), you can enable further parallelization for tasks on the replica. After setting this system variable, the replica will create a specified number of worker threads to apply the transaction, and a coordination thread to manage the transaction. If you are using multiple replication channels, each channel has this number of threads. A copy with slave_parallel_workers set to a value greater than 0 is called a multi-threaded copy. With this setting, failed transactions can be retried.