MariaDB's replication implementation requires several types of threads.
Threads on the Master
The master usually only has one type of replication-related thread: the binary log dump thread.
If semisynchronous replication is enabled, then the master also has an ACK receiver thread.
Binary Log Dump Thread
The binary log dump thread runs on the master and dumps the binary log to the slave. This thread can be identified by running the
SHOW PROCESSLIST statement and finding the thread where the thread command is
The master creates a separate binary log dump thread for each slave connected to the master. You can identify which slaves are connected to the master by executing the
SHOW SLAVE HOSTS statement.
ACK Receiver Thead
When semisynchronous replication is enabled, semisynchronous slaves send acknowledgements (ACKs) to their master confirm that they have received some transaction. The master creates an ACK receiver thread to receive these ACKs.
Threads on the Slave
The slave has three types of replication-related threads: the slave I/O thread, the slave SQL thread, and worker threads, which are only applicable when parallel replication is in use.
When multi-source replication is in use, each independent replication connection has its own slave threads of each type.
Slave I/O Thread
Binary Log Position
The binary log position of the slave's I/O thread and the values of most other
CHANGE MASTER options are written to either the default
master.info file or the file that is configured by the
master_info_file option. The slave's I/O thread keeps this binary log position updated as it downloads events. See CHANGE MASTER TO: Option Persistence for more information
Slave SQL Thread
The slave's SQL thread reads events from the relay log. What it does with them depends on whether parallel replication is in use. If parallel replication is not in use, then the SQL thread applies the events to its local copy of the data. If parallel replication is in use, then the SQL thread hands off the events to its worker threads to apply in parallel.
Relay Log Position
The relay log position of the slave's SQL thread is written to either the default
relay-log.info file or the file that is configured by the
relay_log_info_file system variable. The slave's SQL thread keeps this relay log position updated as it applies events. See CHANGE MASTER TO: Option Persistence for more information.
Binary Log Position
The corresponding binary log position of the current relay log position of the slave's SQL thread can be checked by executing the
SHOW SLAVE STATUS statement. It will be shown as the
If the slave is replicating binary log events that contain GTIDs, then the slave's SQL thread will write every GTID that it applies to the
mysql.gtid_slave_pos table. This GTID can be inspected and modified through the
gtid_slave_pos system variable.
If the slave has the
log_slave_updates system variable enabled and if the slave has the binary log enabled, then every write by the slave's SQL thread will also go into the slave's binary log. This means that GTIDs of replicated transactions would be reflected in the value of the
gtid_binlog_pos system variable.
See CHANGE MASTER TO: GTID Persistence for more information.
When parallel replication is in use, then the SQL thread hands off the events to its worker threads to apply in parallel.